Re: login failed @ koji.fedoraproject.org
Have you imported your FAS SSL certificate in Firefox? https://fedoraproject.org/wiki/Using_the_Koji_build_system#The_web_interface Anyway, for canceling tasks I found more straightforward the use of commandline: "koji cancel-task 12024149" Mattia Il 02/12/2015 05:52, gil ha scritto: hi I tried to log in to stop http://koji.fedoraproject.org/koji/taskinfo?taskID=12024149 but it failed with the following error using Firefox on Fedora 23 koji.fedoraproject.org. Il peer SSL ha rifiutato il certificato considerandolo revocato. (Codice di errore: ssl_error_revoked_cert_alert) any ideas? Thanks in advance Regards - gil -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
Hello Neal, > On Wednesday, 2 December 2015 1:03 AM, Neal Becker wrote: > For example, when I'm at work, I can access hostA.work.com > where resolving hostA only works by talking to dnsserverA.work.com, > which was setup by the usual dhcp and then when I'm at home > > google.com is resolved as normal, using my ISP's dhcp to configure dns. > And this must work without the user ever editing some unbound config file. Yes, it does work that way. The proposed solution(tools) is available in current Fedora repositories and is easy to set-up and test. -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test Please let us know if you face any difficulties. Thank you. --- -P J P http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: login failed @ koji.fedoraproject.org
Il 02/12/2015 05:52, gil ha scritto: hi I tried to log in to stop http://koji.fedoraproject.org/koji/taskinfo?taskID=12024149 but it failed with the following error using Firefox on Fedora 23 koji.fedoraproject.org. Il peer SSL ha rifiutato il certificato considerandolo revocato. (Codice di errore: ssl_error_revoked_cert_alert) koji.fedora project.org. The peer SSL certificate refused considering it revoked. (Error code: ssl_error_revoked_cert_alert) any ideas? Thanks in advance Regards - gil -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
login failed @ koji.fedoraproject.org
hi I tried to log in to stop http://koji.fedoraproject.org/koji/taskinfo?taskID=12024149 but it failed with the following error using Firefox on Fedora 23 koji.fedoraproject.org. Il peer SSL ha rifiutato il certificato considerandolo revocato. (Codice di errore: ssl_error_revoked_cert_alert) any ideas? Thanks in advance Regards - gil -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
RFC: switching from grubby to grub2-mkconfig
Since the old proposal to have the bootloader automatically enumerate boot options never went anywhere, can we do the next best thing? Specifically, these days grub2-mkconfig appears to produce output that's functionally identical to what grubby generates. Can we switch new-kernel-pkg to just regenerate the grub2 config using grub2-mkconfig instead of using grubby? Debian has worked like this forever, and IMO it's superior in pretty much all respects. There are already nice config hooks for making custom changes, and they're a lot more reliable than trusting grubby to do what you expect it to do. --Andy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: conditionalizing %license
On Ter, 2015-12-01 at 16:44 +, Dave Love wrote:
> What's the correct way to write a spec file that obeys the %license*
> stipulation but also works for epel6?
>
> Some time ago I was told to follow
> https://fedorahosted.org/fpc/ticket/411 and write
>
> %{!?_licensedir:%global license %%doc}
>
> and that now also appears in
> https://fedoraproject.org/wiki/EPEL:Packaging?rd=Packaging:EPEL#The_.
> 25license_tag
https://fedoraproject.org/wiki/EPEL:Packaging#The_.25license_tag
have the correct form :
%{!?_licensedir:%global license %doc}
> I now realize it's not working in any non-el5/6 mock root I've tried,
> because the macro isn't defined (according to "rpmbuild --showrc"),
> only
> _defaultlicensedir is.
>
> Is the instruction simply wrong, or am I missing something?
>
> _
> * I keep writing "licence", which is the noun in English English.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.
> org
--
Sérgio M. B.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
rdcp package review
Hi, I'm new here and followed the instructions for adding a new package. I have submitted a ticket for my first package and looking for a review and a sponsor. https://bugzilla.redhat.com/show_bug.cgi?id=1286539 Let me know if I'm missing something. Thanks, Roi -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Fedora 24 Boost 1.60 uplift
Am 01.12.2015 um 22:15 schrieb Richard W.M. Jones: On Tue, Dec 01, 2015 at 02:57:53PM +, Jonathan Wakely wrote: On 28/11/15 20:05 +, Richard W.M. Jones wrote: On Fri, Nov 27, 2015 at 09:24:21AM +0100, Jan Kurik wrote: = System Wide Change: Fedora 24 Boost 1.60 uplift = Does this mean "upgrade" or "update"? I just copied that from the previous change proposals, but I'm not sure what the difference between update and upgrade is in this context. Which should be it be? I mean why call an update to a package an "uplift"? ask that the DNF developers which deprecated "update" to replace with "upgrade" :-) Update Command dnf [options] update Deprecated alias for the Upgrade Command. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Fedora 24 Boost 1.60 uplift
On Tue, Dec 01, 2015 at 09:15:38PM +, Richard W.M. Jones wrote: > On Tue, Dec 01, 2015 at 02:57:53PM +, Jonathan Wakely wrote: > > On 28/11/15 20:05 +, Richard W.M. Jones wrote: > > >On Fri, Nov 27, 2015 at 09:24:21AM +0100, Jan Kurik wrote: > > >>= System Wide Change: Fedora 24 Boost 1.60 uplift = > > > > > >Does this mean "upgrade" or "update"? > > > > I just copied that from the previous change proposals, but I'm not > > sure what the difference between update and upgrade is in this > > context. > > > > Which should be it be? > > I mean why call an update to a package an "uplift"? Let me reconsider this reply, since I don't know if you're a native English speaker. "uplift" is a rather pretentious word which means a raising to a higher intellectual or spiritual level (https://en.wiktionary.org/wiki/uplift has links to the definition in other languages on the left hand column). "upgrade" or "update" (pretty much the same thing) would be the normal way to describe a simple updated version of some software, which I think is more appropriate here. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Fedora 24 Boost 1.60 uplift
On Tue, Dec 01, 2015 at 02:57:53PM +, Jonathan Wakely wrote: > On 28/11/15 20:05 +, Richard W.M. Jones wrote: > >On Fri, Nov 27, 2015 at 09:24:21AM +0100, Jan Kurik wrote: > >>= System Wide Change: Fedora 24 Boost 1.60 uplift = > > > >Does this mean "upgrade" or "update"? > > I just copied that from the previous change proposals, but I'm not > sure what the difference between update and upgrade is in this > context. > > Which should be it be? I mean why call an update to a package an "uplift"? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Review swap
On Tue, Dec 1, 2015 at 12:43 PM, gil wrote: > Hi > again thanks > no all jsonld-java-tools dependencies are all available in rawhide > org.openrdf.sesame: and in F23 only jsonld-java > with fedora-review -b 1267890 --plugins Java -m fedora-rawhide-i386 > should work ... I had to add --enablerepo=local to the mock flags, and now fedora-review is happy. > i try to build before in my system and now on koji [1] mathicgb > but seem there are some problems on i386 arch ... Okay, I'll look into it. Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Package review skipped and straight to repos?
On Tue, Dec 01, 2015 at 08:19:04AM -0500, Matthew Miller wrote: > On Sun, Nov 29, 2015 at 10:09:58PM +, Zbigniew Jędrzejewski-Szmek wrote: > FWIW, I'm not sure that's really true. The fedora-review tool makes it > very easy to do a low-effort review and still produce a pretty > checklist. (This isn't necessarily a bad thing, but it definitely means > that presence of a checklist doesn't indicate particular diligence.) I don't think that's so. fedora-review produces a template half-full of empty boxes, and yes, you can tick them without actually performing the checks, but that would be deception. Our process is not designed to guard against deception, only against mistakes or ignorance. > > Package review is public and happens in the review bug. We also > > require (in the sense of having a strong custom, maybe even if it's > > not written anywhere explicitly), a checklist style review. This allows > > If we want it to be a requirement, we should write it down. In my experience, we err much more on the side of nitpicking and formality in reviews. I think the guidelines are fine as they are. (Also, there are some packages where large parts of any checklist would not apply. This is especially true for packages containing keys, or data, or some config stuff. If we added a *requirement*, we would also have to add so many possible exceptions to make the rules very soft anyway.) Zbyszek -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Review swap
Il 01/12/2015 19:57, Jerry James ha scritto: On Tue, Dec 1, 2015 at 10:42 AM, gil wrote: Hi Jerry, Take! can you take this for me https://bugzilla.redhat.com/show_bug.cgi?id=1267890 ? Will do. It seems this package depends on other packages that have not yet been built in Rawhide. I can build them myself, except I could use some help with the opencsv update. I don't see an updated spec file anywhere. Or is that not necessary? Thanks, Hi again thanks no all jsonld-java-tools dependencies are all available in rawhide org.openrdf.sesame: and in F23 only jsonld-java with fedora-review -b 1267890 --plugins Java -m fedora-rawhide-i386 should work ... i try to build before in my system and now on koji [1] mathicgb but seem there are some problems on i386 arch ... turn off the system ... regards - gil [1] Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=12024149 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: conditionalizing %license
On Tue, Dec 1, 2015 at 1:22 PM, Dave Love wrote:
>
> Sorry, I don't understand. What do I need to get _licensedir defined
> appropriately so that the conditional makes sense (per the chopped part
> of my message)?
%{!?_licensedir:%global license %doc}
%license COPYING
The redirect to doc works with %doc not %%doc.
Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
I think in order to make dnssec/local resolver the default, it should be required to work for a naive user who works in a changing environment such as: moving between work, which has it's own private dns and home, which has usual, public dns without that user needing to understand anything about configuring the components. For example, when I'm at work, I can access hostA.work.com where resolving hostA only works by talking to dnsserverA.work.com, which was setup by the usual dhcp and then when I'm at home google.com is resolved as normal, using my ISP's dhcp to configure dns. And this must work without the user ever editing some unbound config file. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: conditionalizing %license
Richard Shaw writes:
> On Tue, Dec 1, 2015 at 10:44 AM, Dave Love wrote:
>
>> What's the correct way to write a spec file that obeys the %license*
>> stipulation but also works for epel6?
>>
>> Some time ago I was told to follow
>> https://fedorahosted.org/fpc/ticket/411 and write
>>
>> %{!?_licensedir:%global license %%doc}
>>
>> and that now also appears in
>>
>> https://fedoraproject.org/wiki/EPEL:Packaging?rd=Packaging:EPEL#The_.25license_tag
>
>
> Yeah, I ran into the same problem, turns out you don't need the double % in
> front of doc, then it works as expected.
Sorry, I don't understand. What do I need to get _licensedir defined
appropriately so that the conditional makes sense (per the chopped part
of my message)?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Review swap
On Tue, Dec 1, 2015 at 10:42 AM, gil wrote: > Hi Jerry, > Take! > can you take this for me https://bugzilla.redhat.com/show_bug.cgi?id=1267890 > ? Will do. It seems this package depends on other packages that have not yet been built in Rawhide. I can build them myself, except I could use some help with the opencsv update. I don't see an updated spec file anywhere. Or is that not necessary? Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Review swap
Hi Jerry, Take! can you take this for me https://bugzilla.redhat.com/show_bug.cgi?id=1267890 ? Thanks Regards - gil Il 01/12/2015 18:29, Jerry James ha scritto: I need a review for this package: mathicgb: https://bugzilla.redhat.com/show_bug.cgi?id=1287183 Let me know what I can review for you in exchange. Thanks, -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Review swap
I need a review for this package: mathicgb: https://bugzilla.redhat.com/show_bug.cgi?id=1287183 Let me know what I can review for you in exchange. Thanks, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
F24 System Wide Change: Node.js 4.2
= Proposed F24 System Wide Change: Node.js 4.2 = https://fedoraproject.org/wiki/Changes/NodeJS4x Change owner(s): * Stephen Gallagher * Jared Smith Fedora 24 will be updated to Node.js 4.2, the latest LTS release of the platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. == Detailed Description == Node.js has seen many changes between v0.10 and v4.x. There is a listing of changes documented on the wiki:https://github.com/nodejs/node/wiki/API-changes-between-v0.10-and-v4 Note that this release includes API updates that may require dependency updates. Following are some highlights:https://fedoraproject.org/wiki/Changes/NodeJS4x#Detailed_Description == Scope == Proposal owners: * Update v8 * Update nodejs * Rebuild all binary modules, apply patches as necessary * Update npm Other developers: * Other Node.js packagers' attention may be required if the update causes issues for their packages. Release engineering: * Upgrade will require a side-tag to coordinate updates. Policies and guidelines: * Some minor updates to the Node.js guidelines are planned, however they are just Nice To Have for the purposes of this specific change. Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: conditionalizing %license
On Tue, Dec 1, 2015 at 10:44 AM, Dave Love wrote:
> What's the correct way to write a spec file that obeys the %license*
> stipulation but also works for epel6?
>
> Some time ago I was told to follow
> https://fedorahosted.org/fpc/ticket/411 and write
>
> %{!?_licensedir:%global license %%doc}
>
> and that now also appears in
>
> https://fedoraproject.org/wiki/EPEL:Packaging?rd=Packaging:EPEL#The_.25license_tag
Yeah, I ran into the same problem, turns out you don't need the double % in
front of doc, then it works as expected.
Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On Tue, 1 Dec 2015, Randy Barlow wrote: This sounds overall pretty neat to me! One detail came to my mind: how would this interact with VPN DNS servers? In my experience with VPNs, it's common for them to provide a DNS server that allows internal host resolution to work. Would this local resolver be notified by NM of a new VPN connection so that it knows to use the VPN-provided DNS server for hosts on that particular domain, rather than the usual external records for that same domain? Yes, this already works in most VPN implementations shipped with Fedora. (libreswan/IPsec, vpnc/IPsec, openvpn, and probably openconnect) For IPsec, that support will be extended for IKEv2 in the future too, see https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/ The running unbound DNS server will be told to "forward" certain domains to certain IPs of nameservers received during the VPN negotiation. It will remove the forward when the VPN connection goes down. And for those domains, the cache is flushed on each event too, to prevent using stale data that is only used when the VPN is up (or down) Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
conditionalizing %license
What's the correct way to write a spec file that obeys the %license*
stipulation but also works for epel6?
Some time ago I was told to follow
https://fedorahosted.org/fpc/ticket/411 and write
%{!?_licensedir:%global license %%doc}
and that now also appears in
https://fedoraproject.org/wiki/EPEL:Packaging?rd=Packaging:EPEL#The_.25license_tag
I now realize it's not working in any non-el5/6 mock root I've tried,
because the macro isn't defined (according to "rpmbuild --showrc"), only
_defaultlicensedir is.
Is the instruction simply wrong, or am I missing something?
_
* I keep writing "licence", which is the noun in English English.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On Tue, 1 Dec 2015, Björn Persson wrote: Tomas Hozza wrote: - dnssec-trigger does not do the Captive Portal detection and handling and we rather rely on NM for the detection and on Gnome Shell for the Portal login Can I assume that users of non-Gnome desktops will also be able to log in to a portal if they want to? If you can do so now, then you will in the future as well? The idea here is that dnssec-trigger will no longer fire up its own portal login page, but leave it to the OS/Desktop. Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: pkgdb branches requests
On Di, Dez 01, 2015 at 11:29:25 -0500, Jaroslav Skarvada wrote: > I received mail that EPEL-7 branch was requested for PowerTOP in [1]. > Is there any way how to cancel (or at least comment) such requests? You can block it at: https://admin.fedoraproject.org/pkgdb/package/requests/1976 It should be linked at the packages overview after you logged in: https://admin.fedoraproject.org/pkgdb/package/powertop/ Regards Till -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: pkgdb branches requests
On Tue, Dec 1, 2015 at 10:29 AM, Jaroslav Skarvada wrote: > Hi, > > I received mail that EPEL-7 branch was requested for PowerTOP in [1]. > Is there any way how to cancel (or at least comment) such requests? IIRC you can change the request to "Obsolete" but you can't delete it. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
pkgdb branches requests
Hi, I received mail that EPEL-7 branch was requested for PowerTOP in [1]. Is there any way how to cancel (or at least comment) such requests? Because this request is apparently invalid, PowerTOP is already included in RHEL-7 thanks & regards Jaroslav [1] https://admin.fedoraproject.org/pkgdb/package/powertop/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
This sounds overall pretty neat to me! One detail came to my mind: how would this interact with VPN DNS servers? In my experience with VPNs, it's common for them to provide a DNS server that allows internal host resolution to work. Would this local resolver be notified by NM of a new VPN connection so that it knows to use the VPN-provided DNS server for hosts on that particular domain, rather than the usual external records for that same domain? -- Randy Barlow xmpp: bowlofe...@electronsweatshop.com irc: bowlofeggs on Freenode signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 01.12.2015 16:06, Björn Persson wrote: > Tomas Hozza wrote: > > - dnssec-trigger does not do the Captive Portal detection and handling and > > we rather rely on NM for the detection and on Gnome Shell for the Portal > > login > > Can I assume that users of non-Gnome desktops will also be able to log > in to a portal if they want to? Yes, it should be possible. You would need to install the dnssec-trigger-panel. Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF could improve messages about package auto-removal
On Tue, Dec 1, 2015 at 3:02 AM, Petr Spacek wrote: > On 1.12.2015 08:20, Dan Book wrote: > > I have run into this before and it was very confusing, it really should > be > > a separate command from remove for when you actually want to remove what > > dnf thinks is now "unused". > > Maybe it would help if these auto-removed packages are clearly marked as > such > in summary printed by DNF. > > Currently the output looks like this: > $ dnf remove ekiga > Dependencies resolved. > = > Removing: > ekiga x86_64 4.0.1-17.fc22 @fedora 19 M > evolution-data-server x86_64 3.16.5-1.fc22 @updates 14 M > geocode-glib x86_64 3.16.2-1.fc22 @fedora 160 k > gnome-online-accounts x86_64 3.16.4.1-1.fc22 @updates 4.0 M > libgdata x86_64 0.17.3-1.fc22 @updates 1.7 M > ... and so on > > It would be easier to understand if it printed: > > $ dnf remove ekiga > Dependencies resolved. > = > Removing: > ekiga x86_64 4.0.1-17.fc22 @fedora 19 M > Removing unused dependencies: > evolution-data-server x86_64 3.16.5-1.fc22 @updates 14 M > geocode-glib x86_64 3.16.2-1.fc22 @fedora 160 k > gnome-online-accounts x86_64 3.16.4.1-1.fc22 @updates 4.0 M > libgdata x86_64 0.17.3-1.fc22 @updates 1.7 M > > ... and so on > > Petr^2 Spacek > This would be a great improvement indeed. -Dan > > > > > On Tue, Dec 1, 2015 at 1:38 AM, Panu Matilainen < > pmati...@laiskiainen.org> > > wrote: > > > >> On 12/01/2015 07:02 AM, Christopher wrote: > >> > >>> What's the deal with libreoffice packages being a dependency for so > many > >>> system library packages? > >>> > >>> I try to `sudo dnf remove libreoffice\*` and it grabs a bunch of > >>> surprising > >>> packages with it, including some fonts and system libraries. Granted, I > >>> don't think I need any of these things, so it's probably safe to > uninstall > >>> them, but it is surprising that so many packages depend on libreoffice > >>> packages. I'd normally expect the dependencies to be the other way > around > >>> (libreoffice-* depending on system libraries some basic fonts, while > other > >>> fonts are independent or have only optional dependencies on > LibreOffice). > >>> > >>> I don't need or want an offline office suite (it's huge, and takes up > >>> bandwidth during updates). I don't mind uninstalling it after a fresh > >>> install, but it is surprising how much goes with it. > >>> > >> > >> > >> > http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#clean-requirements-on-remove-on-by-default > >> > >> > http://dnf.readthedocs.org/en/latest/conf_ref.html#clean-requirements-on-remove-label > >> > >> Its not that system libraries depend on libreoffice but libreoffice > being > >> the sole user of those libraries, and dnf offering to remove the > otherwise > >> unused cruft along with it. > >> > >> - Panu - > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: LibreOffice packaging is a messy dependency graph
Thank you for the information, but it is still confusing. What I mean by that is that there is no discoverability to why dnf is choosing to remove all the extra packages. So the user is left to assume that none of those packages can function without the one you want to remove. I spent half an hour trying to get dnf to remove a single package with nothing depending on it and eventually gave up and used rpm -e. It was only a day or two later when I saw the new dnf behavior being discussed on IRC that I realized what it was trying to do. On Tue, Dec 1, 2015 at 3:42 AM, Igor Gnatenko wrote: > > http://dnf.readthedocs.org/en/latest/command_ref.html#autoremove-command-label > > dnf autoremove will just remove dependencies which is not used by > another packages. > > BTW you can ignore removing non-used packages for one transaction > using option --setopt=clean_requirements_on_remove=false > > On Tue, Dec 1, 2015 at 8:29 AM, Igor Gnatenko > wrote: > > # dnf autoremove > > > > On Tue, Dec 1, 2015 at 8:21 AM Dan Book wrote: > >> > >> I have run into this before and it was very confusing, it really should > be > >> a separate command from remove for when you actually want to remove > what dnf > >> thinks is now "unused". > >> > >> On Tue, Dec 1, 2015 at 1:38 AM, Panu Matilainen < > pmati...@laiskiainen.org> > >> wrote: > >>> > >>> On 12/01/2015 07:02 AM, Christopher wrote: > > What's the deal with libreoffice packages being a dependency for so > many > system library packages? > > I try to `sudo dnf remove libreoffice\*` and it grabs a bunch of > surprising > packages with it, including some fonts and system libraries. Granted, > I > don't think I need any of these things, so it's probably safe to > uninstall > them, but it is surprising that so many packages depend on libreoffice > packages. I'd normally expect the dependencies to be the other way > around > (libreoffice-* depending on system libraries some basic fonts, while > other > fonts are independent or have only optional dependencies on > LibreOffice). > > I don't need or want an offline office suite (it's huge, and takes up > bandwidth during updates). I don't mind uninstalling it after a fresh > install, but it is surprising how much goes with it. > >>> > >>> > >>> > >>> > http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#clean-requirements-on-remove-on-by-default > >>> > >>> > http://dnf.readthedocs.org/en/latest/conf_ref.html#clean-requirements-on-remove-label > >>> > >>> Its not that system libraries depend on libreoffice but libreoffice > being > >>> the sole user of those libraries, and dnf offering to remove the > otherwise > >>> unused cruft along with it. > >>> > >>> - Panu - > >>> -- > >>> devel mailing list > >>> devel@lists.fedoraproject.org > >>> > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > >> > >> > >> -- > >> devel mailing list > >> devel@lists.fedoraproject.org > >> > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > > > > -- > > > > -Igor Gnatenko > > > > -- > -Igor Gnatenko > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide 20151201 compose check report
Missing expected images: Cloud disk raw i386 Cloud disk raw x86_64 Cloud_atomic disk raw x86_64 No images in this compose but not Rawhide 20151130 No images in Rawhide 20151130 but not this. Failed openQA tests: 52 of 52 ID: 9330Test: x86_64 workstation_live default_install@uefi ID: 9329Test: x86_64 workstation_live default_install ID: 9328Test: x86_64 kde_live default_install ID: 9327Test: i386 workstation_live default_install ID: 9326Test: i386 kde_live default_install ID: 9325Test: x86_64 universal upgrade_desktop_64bit ID: 9324Test: i386 generic_boot default_install ID: 9323Test: x86_64 generic_boot default_install@uefi ID: 9322Test: x86_64 generic_boot default_install ID: 9321Test: i386 universal upgrade_desktop_32bit ID: 9320Test: i386 universal server_lvmthin ID: 9319Test: i386 universal server_ext3 ID: 9318Test: i386 universal server_btrfs ID: 9317Test: i386 universal server_software_raid ID: 9316Test: i386 universal server_simple_encrypted ID: 9315Test: i386 universal server_repository_http_graphical ID: 9314Test: i386 universal server_scsi_updates_img ID: 9313Test: i386 universal package_set_minimal ID: 9312Test: x86_64 universal server_no_swap@uefi ID: 9311Test: x86_64 universal server_lvmthin@uefi ID: 9310Test: x86_64 universal server_ext3@uefi ID: 9309Test: x86_64 universal server_btrfs@uefi ID: 9308Test: x86_64 universal server_software_raid@uefi ID: 9307Test: x86_64 universal server_multi_empty@uefi ID: 9306Test: x86_64 universal server_simple_free_space@uefi ID: 9305Test: x86_64 universal server_simple_encrypted@uefi ID: 9304Test: x86_64 universal server_delete_partial@uefi ID: 9303Test: x86_64 universal server_delete_pata@uefi ID: 9302Test: x86_64 universal server_sata_multi@uefi ID: 9301Test: x86_64 universal european_language_install ID: 9300Test: x86_64 universal server_shrink_ntfs ID: 9299Test: x86_64 universal server_shrink_ext4 ID: 9298Test: x86_64 universal server_updates_img_local ID: 9296Test: x86_64 universal upgrade_minimal_64bit ID: 9295Test: x86_64 universal server_kickstart_hdd ID: 9294Test: x86_64 universal server_no_swap ID: 9293Test: x86_64 universal server_lvmthin ID: 9292Test: x86_64 universal server_ext3 ID: 9291Test: x86_64 universal server_btrfs ID: 9290Test: x86_64 universal server_software_raid ID: 9289Test: x86_64 universal server_multi_empty ID: 9288Test: x86_64 universal server_simple_free_space ID: 9287Test: x86_64 universal server_simple_encrypted ID: 9286Test: x86_64 universal server_delete_partial ID: 9285Test: x86_64 universal server_repository_http_variation ID: 9284Test: x86_64 universal server_repository_http_graphical ID: 9283Test: x86_64 universal server_mirrorlist_graphical ID: 9282Test: x86_64 universal server_delete_pata ID: 9281Test: x86_64 universal server_kickstart_user_creation ID: 9280Test: x86_64 universal server_scsi_updates_img ID: 9279Test: x86_64 universal server_sata_multi ID: 9278Test: x86_64 universal package_set_minimal -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
Tomas Hozza wrote: > - dnssec-trigger does not do the Captive Portal detection and handling and > we rather rely on NM for the detection and on Gnome Shell for the Portal > login Can I assume that users of non-Gnome desktops will also be able to log in to a portal if they want to? Björn Persson pgpw0576kFeWU.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: criterion proposal: upgrading across 2 releases
On 12/01/2015 12:45 PM, Kamil Paral wrote: > Hello, > > a week ago I proposed a new release criterion for upgrading across two > releases (e.g. from F21 to F23 directly, skipping F22). As this was never > officially supported (even though users were probably unaware of this fact, > because we haven't discouraged it either), I'm gathering feedback from > multiple parties. You can read my original proposal below, and you can see > the existing discussion on test list here: > https://lists.fedoraproject.org/archives/list/test%40lists.fedoraproject.org/thread/ANF2WSTHM7EEFL3KOD2EVYSKMOMDRDWP/ > > In a nutshell, QA team is OK with supporting this, and Will Woods as > dnf-plugin-system-upgrade maintainer as well. What I would like to see is > some general feedback from package maintainers, because this will require all > packages to be able to upgrade while skipping a release. As I said, many > users already assume this works and according to our history it does in the > majority of cases, but now it would become even more important. > > Also, as one person mentioned, Richard Hughes might be implementing graphical > support for system upgrade in Fedora 24. Richard, if you can add your > opinion, that would be very welcome as well. If you're going to just call > dnf-plugin-system-upgrade in the background, hopefully there should be no > complications, since it's going to support it (and it already does). Yes, graphical system upgrades are in the works. Supporting upgrades across 2 releases is not a problem at all. It needs a bit more code than just a supporting a single version upgrade, but that's fine. :) Right now the code we have only supports a single version upgrade, but once it's working well, we'll make it work for upgrades across 2 releases as well. Here's mockups how it would look: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/software/version2/wire-upgrades.png (Think "Fedora 24" instead of "GNOME 3.16" when reading this) With my packager hat on, it would be great if we could get this in the packaging guidelines as well, so that there's a canonical source that says that obsoletes/conflicts etc must be preserved to support upgrades across 2 releases. And also maybe make some noise in devel-announce and in the fedora magazine so that packagers are aware that this is something everybody needs to support. -- Kalev -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Fedora 24 Boost 1.60 uplift
On 28/11/15 20:05 +, Richard W.M. Jones wrote: On Fri, Nov 27, 2015 at 09:24:21AM +0100, Jan Kurik wrote: = System Wide Change: Fedora 24 Boost 1.60 uplift = Does this mean "upgrade" or "update"? I just copied that from the previous change proposals, but I'm not sure what the difference between update and upgrade is in this context. Which should be it be? -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF could improve messages about package auto-removal
On 01/12/15 09:02 +0100, Petr Spacek wrote: On 1.12.2015 08:20, Dan Book wrote: I have run into this before and it was very confusing, it really should be a separate command from remove for when you actually want to remove what dnf thinks is now "unused". Maybe it would help if these auto-removed packages are clearly marked as such in summary printed by DNF. Currently the output looks like this: $ dnf remove ekiga Dependencies resolved. = Removing: ekiga x86_64 4.0.1-17.fc22 @fedora 19 M evolution-data-server x86_64 3.16.5-1.fc22 @updates 14 M geocode-glib x86_64 3.16.2-1.fc22 @fedora 160 k gnome-online-accounts x86_64 3.16.4.1-1.fc22 @updates 4.0 M libgdata x86_64 0.17.3-1.fc22 @updates 1.7 M ... and so on It would be easier to understand if it printed: $ dnf remove ekiga Dependencies resolved. = Removing: ekiga x86_64 4.0.1-17.fc22 @fedora 19 M Removing unused dependencies: evolution-data-server x86_64 3.16.5-1.fc22 @updates 14 M geocode-glib x86_64 3.16.2-1.fc22 @fedora 160 k gnome-online-accounts x86_64 3.16.4.1-1.fc22 @updates 4.0 M libgdata x86_64 0.17.3-1.fc22 @updates 1.7 M ... and so on Yes please!! It would be a huge improvement to make almost **any** visual distinction between this auto-removal and the traditional case we're all used to. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Can Koji handle a soname change and a self-dependency?
Kevin Fenzi wrote: > On Sun, 29 Nov 2015 00:35:37 +0100 > Björn Persson wrote: > > > Is there a way to deal with the following situation in Koji? > > > > · Build tool B has a build-time dependency on itself. > > · B is linked to library L version 1. > > · L gets upgraded to version 2, which changes its soname. > > > > B needs to be rebuilt to link to libL.so.2, but building B requires > > a working B, which requires libL.so.1 because it hasn't been rebuilt > > yet. > > > > As I understand it, when the L-2 package goes into the buildroot it > > immediately replaces L-1. Is there a way to keep L-1 available > > until B has been rebuilt? > > Nope. > > > Is the answer to link B statically? > > Nope. > > The usual way to handle this is to add a compat version of the library > (so.1) to L, rebuild B, then drop the compat library, ie just keep it > for one build to rebuild B. So the L source package shall temporarily contain two versions of the source tarball and build them both, and then install one as usual and extract only the binary library from the other? That would complicate the spec quite a bit even in an otherwise simple package, and when the spec is already big and complex ... Time to get specific. L is libgnat, a subpackage of GCC. B is GPRbuild, the builder that builds the Ada packages. GPRbuild is linked to XMLada, and both GPRbuild and XMLada are linked to libgnat, as are all other Ada programs and libraries. With every major GCC upgrade the soname of libgnat changes, and all the Ada packages stop working until they get rebuilt. But rebuilding requires a working GPRbuild. Previously a catch-22 was avoided because XMLada and GPRbuild were built with Gnatmake, which is built as a part of GCC. Now they're both built with GPRbuild instead, and Gnatmake is emitting warnings that it's going to lose support for the project files that control the build. The next GCC upgrade will make the problem acute. So now you're saying that the GCC package, whose spec is already 3000 lines long, needs to contain an entire additional GCC and build large parts of it, just to work around a limitation in Koji? I can of course ask the GCC maintainer, but I fully expect that he'll refuse. And then XMLada must be rebuilt before GPRbuild can be rebuilt. This XMLada build will have to provide a compatibility instance of XMLada linked to the old libgnat, because otherwise both versions of libgnat would be loaded into GPRbuild the next time it runs. For that to be possible, the compatibility version of libgnat must include not only the binary library, but also the old version of the entire content of libgnat-devel, so that the compatibility instance of XMLada can be linked. That in turn means that the old version of the compiler itself must be provided, because GNAT performs consistency checks and won't link code compiled with one version of GNAT to a library compiled with another version of GNAT. In short, this seem like an enormous amount of trouble, mostly in the GCC pacakage. It would be so much easier if the already existing libraries could remain available for a limited time. Björn Persson pgpDyowPzapHD.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Dealing with rolling release versioning
On Mon, Nov 30, 2015 at 02:38:10PM -0500, Jaroslav Skarvada wrote: > they now use 'daily-MMDD' as the version, it is even shown in the > about dialog. They provide daily builds. It doesn't seem they are > going to change this release model in the near future (but I will > recheck with them). Personally I would go with MMDD as the > version. Anytime later, if the release model change, we will be able > to add epoch and use different numbering. Just my two cents Yes, this makes sense to me too. It's not that they no longer have versions, it's that they have daily versions with a naming scheme which corresponds to that. That's presuming that you're actually using the snapshot corresponding to the official daily build, not just a checkout that happens to share the date. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Package review skipped and straight to repos?
On Sun, Nov 29, 2015 at 10:09:58PM +, Zbigniew Jędrzejewski-Szmek wrote: > Package review is public and happens in the review bug. We also > require (in the sense of having a strong custom, maybe even if it's > not written anywhere explicitly), a checklist style review. This allows If we want it to be a requirement, we should write it down. > other people to know that not only the reviewer acked the package, > but that they did it with enough diligence. FWIW, I'm not sure that's really true. The fedora-review tool makes it very easy to do a low-effort review and still produce a pretty checklist. (This isn't necessarily a bad thing, but it definitely means that presence of a checklist doesn't indicate particular diligence.) -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 01.12.2015 13:28, Tomas Mraz wrote: > On Út, 2015-12-01 at 11:15 +0100, Tomas Hozza wrote: > > You are not mistaken. > > > > This is the third time, because previously we rather moved the change to the > > next Fedora to bring better user experience. Every time there was something > > enhanced, since we learned a lot about user use-cases, so this is definitely > > not the same change as before, only the root idea is the same. The Change > > Wiki > > is up-to-date and contains the current information. > > > > Also with many projects involved - Gnome Shell, NetworkManager, Unbound, > > dnssec-trigger, SELinux (always a pleasure:), Docker... it is not the > > easiest > > thing to agree on changes and coordinate everything on time. > > > > What changed from the top of my head: > > - We decided not to install the dnssec-trigger panel by default and rather > > better integrate dnssec-trigger with NM and Gnome Shell > > - We decided not to query user for security decisions, and for the beginning > > if there is no other option just fall back to the current state that that > > is > > in Fedora today > > Will there be at least some visual indicator that the network you're > connected to does not provide secure DNS? Not that the network does not provide secure DNS, but only that the local DNS resolver is not able to use DNSSEC. This information makes sense on the system level, not really on the connection level (although technically it is possible). We are still working on the solution. Nevertheless it should be native WRT the desktop environment on Fedora Workstation. Tomas -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF could improve messages about package auto-removal
On 1.12.2015 13:25, Panu Matilainen wrote: > On 12/01/2015 10:02 AM, Petr Spacek wrote: >> On 1.12.2015 08:20, Dan Book wrote: >>> I have run into this before and it was very confusing, it really should be >>> a separate command from remove for when you actually want to remove what >>> dnf thinks is now "unused". >> >> Maybe it would help if these auto-removed packages are clearly marked as such >> in summary printed by DNF. >> >> Currently the output looks like this: >> $ dnf remove ekiga >> Dependencies resolved. >> = >> Removing: >> ekiga x86_64 4.0.1-17.fc22 @fedora 19 M >> evolution-data-server x86_64 3.16.5-1.fc22 @updates 14 M >> geocode-glib x86_64 3.16.2-1.fc22 @fedora 160 k >> gnome-online-accounts x86_64 3.16.4.1-1.fc22 @updates 4.0 M >> libgdata x86_64 0.17.3-1.fc22 @updates 1.7 M >> ... and so on >> >> It would be easier to understand if it printed: >> >> $ dnf remove ekiga >> Dependencies resolved. >> = >> Removing: >> ekiga x86_64 4.0.1-17.fc22 @fedora 19 M >> Removing unused dependencies: >> evolution-data-server x86_64 3.16.5-1.fc22 @updates 14 M >> geocode-glib x86_64 3.16.2-1.fc22 @fedora 160 k >> gnome-online-accounts x86_64 3.16.4.1-1.fc22 @updates 4.0 M >> libgdata x86_64 0.17.3-1.fc22 @updates 1.7 M >> >> ... and so on >> > > Yes, that'd be MUCH better. > > We're all so conditioned to the yum behavior that anything else seems > suspicious even if it (removing unused cruft) is actually a sane thing to do. I totally agree with you. Hopefully most of the backlash can be mitigated with small improvements to user interface like this one ^^^. -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 Self Contained Change: Koji Generates Repositories of Signed RPMs
On 1.12.2015 13:15, Jan Kurik wrote: > = Proposed Self Contained Change: Koji Generates Repositories of Signed RPMs = > > Change owner(s): > * Jay Greguske < jgregusk with the usual red hat domain > > > Extend Koji with a new feature that allows users to generate yum > repositories of signed RPMs. > > == Detailed Description == > This is a significant enabler for generating DVD media, other ISOs, > and images more efficiently. It also allows other tools such as mash > or pungi to offload much of the heavy-lifting to the build system. > Longer term, we may be able to reduce the number of tools needed to > manufacture Fedora releases. > > == Scope == > Proposal owners: to implement this change > Release engineering: This feature does require coordination with > release engineering (e.g. changes to installer image generation or > update package delivery.) When you are at it, would it be possible to sign repo metadata too, so we can have repo_gpgcheck enabled for official repos? -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On Út, 2015-12-01 at 11:15 +0100, Tomas Hozza wrote: > You are not mistaken. > > This is the third time, because previously we rather moved the change to the > next Fedora to bring better user experience. Every time there was something > enhanced, since we learned a lot about user use-cases, so this is definitely > not the same change as before, only the root idea is the same. The Change Wiki > is up-to-date and contains the current information. > > Also with many projects involved - Gnome Shell, NetworkManager, Unbound, > dnssec-trigger, SELinux (always a pleasure:), Docker... it is not the easiest > thing to agree on changes and coordinate everything on time. > > What changed from the top of my head: > - We decided not to install the dnssec-trigger panel by default and rather > better integrate dnssec-trigger with NM and Gnome Shell > - We decided not to query user for security decisions, and for the beginning > if there is no other option just fall back to the current state that that is > in Fedora today Will there be at least some visual indicator that the network you're connected to does not provide secure DNS? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF could improve messages about package auto-removal
On 12/01/2015 10:02 AM, Petr Spacek wrote: On 1.12.2015 08:20, Dan Book wrote: I have run into this before and it was very confusing, it really should be a separate command from remove for when you actually want to remove what dnf thinks is now "unused". Maybe it would help if these auto-removed packages are clearly marked as such in summary printed by DNF. Currently the output looks like this: $ dnf remove ekiga Dependencies resolved. = Removing: ekiga x86_64 4.0.1-17.fc22 @fedora 19 M evolution-data-server x86_64 3.16.5-1.fc22 @updates 14 M geocode-glib x86_64 3.16.2-1.fc22 @fedora 160 k gnome-online-accounts x86_64 3.16.4.1-1.fc22 @updates 4.0 M libgdata x86_64 0.17.3-1.fc22 @updates 1.7 M ... and so on It would be easier to understand if it printed: $ dnf remove ekiga Dependencies resolved. = Removing: ekiga x86_64 4.0.1-17.fc22 @fedora 19 M Removing unused dependencies: evolution-data-server x86_64 3.16.5-1.fc22 @updates 14 M geocode-glib x86_64 3.16.2-1.fc22 @fedora 160 k gnome-online-accounts x86_64 3.16.4.1-1.fc22 @updates 4.0 M libgdata x86_64 0.17.3-1.fc22 @updates 1.7 M ... and so on Yes, that'd be MUCH better. We're all so conditioned to the yum behavior that anything else seems suspicious even if it (removing unused cruft) is actually a sane thing to do. - Panu - -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
F24 Self Contained Change: Koji Generates Repositories of Signed RPMs
= Proposed Self Contained Change: Koji Generates Repositories of Signed RPMs = Change owner(s): * Jay Greguske < jgregusk with the usual red hat domain > Extend Koji with a new feature that allows users to generate yum repositories of signed RPMs. == Detailed Description == This is a significant enabler for generating DVD media, other ISOs, and images more efficiently. It also allows other tools such as mash or pungi to offload much of the heavy-lifting to the build system. Longer term, we may be able to reduce the number of tools needed to manufacture Fedora releases. == Scope == Proposal owners: to implement this change Release engineering: This feature does require coordination with release engineering (e.g. changes to installer image generation or update package delivery.) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yarock package maintainer not respoding
https://bugzilla.redhat.com/show_bug.cgi?id=1213155 https://bugzilla.redhat.com/show_bug.cgi?id=1285176 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: yarock package maintainer not respoding
https://bugzilla.redhat.com/show_bug.cgi?id=1213155 https://bugzilla.redhat.com/show_bug.cgi?id=1285176 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: redeclipse
https://bugzilla.redhat.com/show_bug.cgi?id=1204600 https://bugzilla.redhat.com/show_bug.cgi?id=1285313 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
urbanterror
game update https://bugzilla.redhat.com/show_bug.cgi?id=1213158 https://bugzilla.redhat.com/show_bug.cgi?id=1121403 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
criterion proposal: upgrading across 2 releases
Hello, a week ago I proposed a new release criterion for upgrading across two releases (e.g. from F21 to F23 directly, skipping F22). As this was never officially supported (even though users were probably unaware of this fact, because we haven't discouraged it either), I'm gathering feedback from multiple parties. You can read my original proposal below, and you can see the existing discussion on test list here: https://lists.fedoraproject.org/archives/list/test%40lists.fedoraproject.org/thread/ANF2WSTHM7EEFL3KOD2EVYSKMOMDRDWP/ In a nutshell, QA team is OK with supporting this, and Will Woods as dnf-plugin-system-upgrade maintainer as well. What I would like to see is some general feedback from package maintainers, because this will require all packages to be able to upgrade while skipping a release. As I said, many users already assume this works and according to our history it does in the majority of cases, but now it would become even more important. Also, as one person mentioned, Richard Hughes might be implementing graphical support for system upgrade in Fedora 24. Richard, if you can add your opinion, that would be very welcome as well. If you're going to just call dnf-plugin-system-upgrade in the background, hopefully there should be no complications, since it's going to support it (and it already does). Thanks, Kamil - Forwarded Message - From: "Kamil Paral" To: "For testing and quality assurance of Fedora releases" Sent: Monday, November 23, 2015 4:52:54 PM Subject: criterion proposal: upgrading across 2 releases Our current upgrade criterion says: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed." https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria#Upgrade_requirements Currently we have no criterion that would cover upgrading across 2 releases, e.g. from F21 to F23 (directly, not one by one). But in the real world this very often happens. It's even one of the reasons we support our releases until N+2 release is available + 1 month (i.e. F21 is supported until F23 is out + 1 month). The often cited reason is for people to be upgrading just once per year (and have one month to do that). And of course many (probably most) of them don't upgrade one by one, but skip a release. I feel that for something as important as system upgrade, we should provide a better level of quality and assurance for upgrading across 2 releases. Currently we have no criterion and testing it is just an afterthought, not even tracked anywhere. I'd like to amend the existing criterion to include N-2 release as well, i.e.: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of any of the two previous stable Fedora releases with that package set installed." (language corrections very welcome) We can discuss whether N+2 upgrading should be a separate Final criterion, not joined with the Beta one. I don't feel strongly either way. I'd also set up a new test case in our installation matrix in the upgrade section: https://fedoraproject.org/wiki/Template:Installation_test_matrix#Upgrade Something like QA:Testcase_upgrade_dnf_skip_release. The question is whether to have just a single test case and let people choose which package set they test, or whether to pick some particular package set. We probably don't want to test all combinations, at least not manually. Just a single "please test something" test case would be satisfactory here, I think. Something will get tested, and we will block on important bugs we discover, that's the important change. If we decide to not go this route for some reason, I think we should adjust our tools (system-upgrade) and documentation (wiki, fedora docs) and provide very clear and visible warning that the only officially supported means of upgrading is to go up releases one by one. And that skipping releases might be dangerous (considerably more than doing it the recommended way). Because I feel we would be doing our users a disservice if we neither tested skipping releases nor warned them against doing that. Thoughts? Kamil -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
rawhide report: 20151201 changes
Compose started at Tue Dec 1 05:15:02 UTC 2015 Broken deps for i386 -- [IQmol] IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2 [alliance] alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2 [eclipse-jbosstools] eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires osgi(org.eclipse.tm.terminal) [fawkes] fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 [fedfind] fedfind-1.6.2-2.fc24.noarch requires python2-cached_property [freesteam] freesteam-ascend-2.1-9.20150903svn761.fc24.i686 requires ascend-libs(x86-32) [gnash] 1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-plugin-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 [golang-github-kraman-libcontainer] golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch requires golang(github.com/docker/docker/pkg/netlink) [golang-github-kubernetes-heapster] golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/info/v1) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/client) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/schema) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/registry) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/pkg) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/machine) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/etcd) golang-github-kubernetes-heapster-de
[Test-Announce]Fedora 24 Rawhide 20151201 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 24 Rawhide 20151201. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: pykickstart - 20151120: 2.20-2, 20151201: 2.21-1 Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/24 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151201_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151201_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151201_Base https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151201_Server https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151201_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151201_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_24_Rawhide_20151201_Security_Lab https://fedoraproject.org/wiki/Template:Fedora_24_Rawhide_20151201_Download Thank you for testing! -- Mail generated by relval: https://www.happyassassin.net/wikitcms/ On behalf of: adamwill ___ test-announce mailing list test-annou...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
You are not mistaken. This is the third time, because previously we rather moved the change to the next Fedora to bring better user experience. Every time there was something enhanced, since we learned a lot about user use-cases, so this is definitely not the same change as before, only the root idea is the same. The Change Wiki is up-to-date and contains the current information. Also with many projects involved - Gnome Shell, NetworkManager, Unbound, dnssec-trigger, SELinux (always a pleasure:), Docker... it is not the easiest thing to agree on changes and coordinate everything on time. What changed from the top of my head: - We decided not to install the dnssec-trigger panel by default and rather better integrate dnssec-trigger with NM and Gnome Shell - We decided not to query user for security decisions, and for the beginning if there is no other option just fall back to the current state that that is in Fedora today - better handling of environments, where the resolvers on the network don't support DNSSEC by new Unbound plugin. This is still not in upstream, since we wanted to get the algorithm to the RFC draft that is currently discussed on IETF WG (http://www.ietf.org/id/draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt) - dnssec-trigger does not do the Captive Portal detection and handling and we rather rely on NM for the detection and on Gnome Shell for the Portal login - Some enhancements of the portal helper in Gnome Shell are being reviewed, (it will not rely on the resolv.conf content and rather use sandboxed environment with resolv.conf containing resolvers for the connection from NM). If you check the "decisions made" part of the change wiki, it discusses the important outcomes of discussions. Some of these things are not polished, implemented or merged upstream yet, but we are working on them with the F24 schedule in mind. We are also communicating with NM and Gnome devels and will discuss the defaults with WGs with some Product, once FESCo approves the change. Regards, Tomas On 01.12.2015 09:14, Vít Ondruch wrote: > If I am not mistaken, this is at least 3rd time this change is proposed. > Can somebody post some short summary what was changed, that you believe > it will be successful this time? > > Thx > > > Vít > > > Dne 30.11.2015 v 17:14 Jan Kurik napsal(a): > > = Default Local DNS Resolver = > > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver > > > > Change owner(s): > > * P J P > > * Pavel Šimerda > > * Tomas Hozza > > * Petr Špaček > > > > Plain DNS protocol is insecure and therefore vulnerable from various > > attacks (e.g. cache poisoning). A client can never be sure that there > > is no man-in-the-middle, if it does not do the DNSSEC validation > > locally. > > We want to have Unbound server installed and running on localhost by > > default on Fedora systems. Where necessary, have also dnssec-trigger > > installed and running by default. Unbound and dnssec-trigger will be > > properly integrated with the default network configuration manager > > (e.g. NetworkManager for Fedora Server and Workstation) and with the > > graphical user interface (especially GNOME). The localhost address > > will be the only record in /etc/resolv.conf and no other software > > except dnssec-trigger will be allowed to change its content. > > > > > > > > == Detailed Description == > > Plain DNS protocol is insecure and therefore vulnerable from various > > attacks (e.g. cache poisoning). DNSSEC is a DNS extension which > > enabled the client to verify the DNS query response and make sure > > there is no attacker to spoof some records. A user connected to > > network usually receives a set of resolvers from DHCP, which should be > > used for name resolution. These resolvers may also do the DNSSEC > > validation. However a client can never be sure that there is no > > man-in-the-middle, if it does not do the DNSSEC validation locally. > > Purpose of this Fedora change is to have a validating DNS resolver > > installed on Fedora systems by default. This includes necessary > > discussions, coordination and integration with other components > > installed on Fedora by default. > > > > There are growing instances of discussions and debates about the need > > for a trusted local validating DNS resolver. There are multiple > > reasons for having such a resolver, most importantly security and > > usability. Security and protection of user's privacy becomes paramount > > with the backdrop of the increasingly snooping governments and service > > providers world wide. > > > > People use Fedora on portable/mobile devices which are connected to > > diverse networks as and when required. The automatic DNS > > configurations provided by these networks are never trustworthy for > > DNSSEC validation, as currently there is no way to establish such > > trust. > > > > Apart from trust, these name servers are often known to be flaky and > > unreliable which only adds to the o
Re: F24 System Wide Change: Default Local DNS Resolver
Hello Vit, > On Tuesday, 1 December 2015 1:45 PM, Vít Ondruch wrote: > > If I am not mistaken, this is at least 3rd time this change is proposed. > Can somebody post some short summary what was changed, that you believe > it will be successful this time? True, it was postponed couple of times because few implementation issues were not resolved properly. There wasn't consensus about how the proposed solution would interact with other components(ex. NM, Gnome shell) on the system.[*] We have managed to sort out those differences and hope to resolve implementation issues to build a strong solution. [*] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver Thank you. --- -P J P http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Upstream DNF?
We are using RedHat Bugzilla to track all bugs which happens in DNF, dnf-plugins-core, dnf-plugins-extras. So please choose right component in https://bugzilla.redhat.com and file a bug. We will be happy to help with it. On Tue, Dec 1, 2015 at 6:43 AM, Igor Gnatenko wrote: > https://bugzilla.redhat.com > > > On Tue, Dec 1, 2015, 6:40 AM Christopher wrote: >> >> Where is the upstream DNF issue tracker? I see the project on GitHub: >> https://github.com/rpm-software-management/dnf >> >> However, there doesn't appear to be a corresponding issue tracker, or >> point of contact to request access to edit Wiki pages (which are locked >> down), etc. In fact, there appears to be only 3 public members of the >> upstream community. >> >> Is this not the canonical location for upstream DNF? If not, does anybody >> know where it is? If it is, I'm a bit concerned about its insular nature. >> >> Apologies if this has been brought up before... I don't recall anything >> recent; also, not interested in ranting/raving about DNF... I've >> deliberately avoided those kinds of threads in the past. I'm just trying to >> find (and subsequently engage with) the correct upstream community. >> >> Thanks. >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > > -- > > -Igor Gnatenko -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: LibreOffice packaging is a messy dependency graph
http://dnf.readthedocs.org/en/latest/command_ref.html#autoremove-command-label dnf autoremove will just remove dependencies which is not used by another packages. BTW you can ignore removing non-used packages for one transaction using option --setopt=clean_requirements_on_remove=false On Tue, Dec 1, 2015 at 8:29 AM, Igor Gnatenko wrote: > # dnf autoremove > > On Tue, Dec 1, 2015 at 8:21 AM Dan Book wrote: >> >> I have run into this before and it was very confusing, it really should be >> a separate command from remove for when you actually want to remove what dnf >> thinks is now "unused". >> >> On Tue, Dec 1, 2015 at 1:38 AM, Panu Matilainen >> wrote: >>> >>> On 12/01/2015 07:02 AM, Christopher wrote: What's the deal with libreoffice packages being a dependency for so many system library packages? I try to `sudo dnf remove libreoffice\*` and it grabs a bunch of surprising packages with it, including some fonts and system libraries. Granted, I don't think I need any of these things, so it's probably safe to uninstall them, but it is surprising that so many packages depend on libreoffice packages. I'd normally expect the dependencies to be the other way around (libreoffice-* depending on system libraries some basic fonts, while other fonts are independent or have only optional dependencies on LibreOffice). I don't need or want an offline office suite (it's huge, and takes up bandwidth during updates). I don't mind uninstalling it after a fresh install, but it is surprising how much goes with it. >>> >>> >>> >>> http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#clean-requirements-on-remove-on-by-default >>> >>> http://dnf.readthedocs.org/en/latest/conf_ref.html#clean-requirements-on-remove-label >>> >>> Its not that system libraries depend on libreoffice but libreoffice being >>> the sole user of those libraries, and dnf offering to remove the otherwise >>> unused cruft along with it. >>> >>> - Panu - >>> -- >>> devel mailing list >>> devel@lists.fedoraproject.org >>> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org >> >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > > -- > > -Igor Gnatenko -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
If I am not mistaken, this is at least 3rd time this change is proposed. Can somebody post some short summary what was changed, that you believe it will be successful this time? Thx Vít Dne 30.11.2015 v 17:14 Jan Kurik napsal(a): > = Default Local DNS Resolver = > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver > > Change owner(s): > * P J P > * Pavel Šimerda > * Tomas Hozza > * Petr Špaček > > Plain DNS protocol is insecure and therefore vulnerable from various > attacks (e.g. cache poisoning). A client can never be sure that there > is no man-in-the-middle, if it does not do the DNSSEC validation > locally. > We want to have Unbound server installed and running on localhost by > default on Fedora systems. Where necessary, have also dnssec-trigger > installed and running by default. Unbound and dnssec-trigger will be > properly integrated with the default network configuration manager > (e.g. NetworkManager for Fedora Server and Workstation) and with the > graphical user interface (especially GNOME). The localhost address > will be the only record in /etc/resolv.conf and no other software > except dnssec-trigger will be allowed to change its content. > > > > == Detailed Description == > Plain DNS protocol is insecure and therefore vulnerable from various > attacks (e.g. cache poisoning). DNSSEC is a DNS extension which > enabled the client to verify the DNS query response and make sure > there is no attacker to spoof some records. A user connected to > network usually receives a set of resolvers from DHCP, which should be > used for name resolution. These resolvers may also do the DNSSEC > validation. However a client can never be sure that there is no > man-in-the-middle, if it does not do the DNSSEC validation locally. > Purpose of this Fedora change is to have a validating DNS resolver > installed on Fedora systems by default. This includes necessary > discussions, coordination and integration with other components > installed on Fedora by default. > > There are growing instances of discussions and debates about the need > for a trusted local validating DNS resolver. There are multiple > reasons for having such a resolver, most importantly security and > usability. Security and protection of user's privacy becomes paramount > with the backdrop of the increasingly snooping governments and service > providers world wide. > > People use Fedora on portable/mobile devices which are connected to > diverse networks as and when required. The automatic DNS > configurations provided by these networks are never trustworthy for > DNSSEC validation, as currently there is no way to establish such > trust. > > Apart from trust, these name servers are often known to be flaky and > unreliable which only adds to the overall bad and at times even > frustrating user experience. In such a situation, having a trusted > local validating DNS resolver not only makes sense but is, in fact, > badly needed. It has become a need of the hour. (See: [1], [2], [3]) > > All DNS literature strongly recommends it and amongst all discussions > and debates about the issues involved in establishing such trust, it > is unanimously agreed upon and accepted that having a trusted local > DNS resolver is the best solution possible. It will simplify and > facilitate a lot of other design decisions and application development > in the future. (See: [1], [2], [3]) > > [1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html > [2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html > [3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html > > > > == Scope == > Proposal owners: Proposal owners shall have to > * define the syntax and semantics for new configuration parameters/files. > * properly document how to test and configure the new default setup > * persuade and coordinate with the other package owners to incorporate > new changes/workflow in their applications. > * discuss with WGs in which products the change makes sense and what > are the expectations of WGs for different Fedora products > * resolve interoperability issues for Docker and other containers use-cases > > Other developers: (especially NetworkManager and the likes) > * NetworkManager has to implement notifications on connectivity state changes > * Gnome Shell has to use the connection provided resolvers (fetched > directly from NM) for Hot-Spot login purposes > * Ideally other developers and user should test their software and > application in this setup and verify that it is working as expected > > Release engineering: > * Make sure that the necessary packages (dnssec-trigger, unbound) are > part of the composes for the appropriate Fedora Products. > * Add services needed for the setup into the default presets > (dnssec-triggerd.service) > > Policies and guidelines: > * Any software, including NetworkManager, will have to be configured > to not tamper with the content of '/etc/resolv.conf' by default. The > c
Re: DNF could improve messages about package auto-removal
On 1.12.2015 08:20, Dan Book wrote: > I have run into this before and it was very confusing, it really should be > a separate command from remove for when you actually want to remove what > dnf thinks is now "unused". Maybe it would help if these auto-removed packages are clearly marked as such in summary printed by DNF. Currently the output looks like this: $ dnf remove ekiga Dependencies resolved. = Removing: ekiga x86_64 4.0.1-17.fc22 @fedora 19 M evolution-data-server x86_64 3.16.5-1.fc22 @updates 14 M geocode-glib x86_64 3.16.2-1.fc22 @fedora 160 k gnome-online-accounts x86_64 3.16.4.1-1.fc22 @updates 4.0 M libgdata x86_64 0.17.3-1.fc22 @updates 1.7 M ... and so on It would be easier to understand if it printed: $ dnf remove ekiga Dependencies resolved. = Removing: ekiga x86_64 4.0.1-17.fc22 @fedora 19 M Removing unused dependencies: evolution-data-server x86_64 3.16.5-1.fc22 @updates 14 M geocode-glib x86_64 3.16.2-1.fc22 @fedora 160 k gnome-online-accounts x86_64 3.16.4.1-1.fc22 @updates 4.0 M libgdata x86_64 0.17.3-1.fc22 @updates 1.7 M ... and so on Petr^2 Spacek > > On Tue, Dec 1, 2015 at 1:38 AM, Panu Matilainen > wrote: > >> On 12/01/2015 07:02 AM, Christopher wrote: >> >>> What's the deal with libreoffice packages being a dependency for so many >>> system library packages? >>> >>> I try to `sudo dnf remove libreoffice\*` and it grabs a bunch of >>> surprising >>> packages with it, including some fonts and system libraries. Granted, I >>> don't think I need any of these things, so it's probably safe to uninstall >>> them, but it is surprising that so many packages depend on libreoffice >>> packages. I'd normally expect the dependencies to be the other way around >>> (libreoffice-* depending on system libraries some basic fonts, while other >>> fonts are independent or have only optional dependencies on LibreOffice). >>> >>> I don't need or want an offline office suite (it's huge, and takes up >>> bandwidth during updates). I don't mind uninstalling it after a fresh >>> install, but it is surprising how much goes with it. >>> >> >> >> http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#clean-requirements-on-remove-on-by-default >> >> http://dnf.readthedocs.org/en/latest/conf_ref.html#clean-requirements-on-remove-label >> >> Its not that system libraries depend on libreoffice but libreoffice being >> the sole user of those libraries, and dnf offering to remove the otherwise >> unused cruft along with it. >> >> - Panu - -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
