devel November 2019

devel@lists.fedoraproject.org

226 participants
296 discussions

Please, IMHO, resolve in some way the Samba MIT kerberos problem.
by Dario Lesca 12 Feb '20

12 Feb '20

Too many people (like also me) try to use samba-dc on fedora for deploy a production AD DC controller, without know that MIT kerberos is experimental and some useful things cannot work (es. win to win access). An recent last example: https://lists.samba.org/archive/samba/2019-November/226845.html > On 01/11/2019 22:23, Vex Mage wrote: > > The script is expecting dpkg however this is a Red Hat > > derived distro (Fedora Server.) > > Where did you get the Samba packages from ? > > If they are the default OS packages, then you should stop using > them, they use MIT kerberos and are experimental. There is many approach for resolve this issue: a) Stop use MIT kerberos and rebuild samba with Heimdal Kerberos. b) Produce a samba alternative package version (like, for example, firefox-x11) build it with Heimdal Kerberos (es samba-hk-*) c) Stop enable DC on Fedora, like RH/Centos do. d) Notify users at the end of the installation that Fedora Samba DC is experimental. e) Solve the problems that make MIT kerberos experimental and put us in a position to ask for help on the samba team. f) ... some other proposal ? What is the best approach chosen by Fedora ? Many thanks -- Dario Lesca (inviato dal mio Linux Fedora 31 Workstation)

10 22

Re: [ovirt-users] [feedback needed] VirtIO Windows Drivers - new installer
by Sandro Bonazzola 04 Feb '20

04 Feb '20

Il giorno gio 24 ott 2019 alle ore 19:28 Strahil <hunter86_bg(a)yahoo.com> ha scritto: > Hi Sandro,All, > > Can I upgrade the tools on existing VM , or it requires a fresh one? Best > Regards > If you have oVirt windows guest tools already installed suggestion is to uninstall it before installing this new installer. > Best Regards, > Strahil Nikolov > On Oct 24, 2019 14:35, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote: > > Hi, > as part of the work on oVirt 4.4, the team rewrote the VirtiIO Windows > Drivers installer using the open source framework WiX. > Thanks to the virtio-win maintainer, the new installer is not shipped > anymore within oVirt Guest Tools ISO: it's shipped now directly into VirtIO > Windows ISO[1] > > Please give it a run on your testing environment / testing VMs and let us > know about your experience at devel(a)ovirt.org. > Thanks, > > > [1] > https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-vi… > > -- > > Sandro Bonazzola > > MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV > > Red Hat EMEA <https://www.redhat.com/> > > sbonazzo(a)redhat.com > <https://www.redhat.com/>*Red Hat respects your work life balance. > Therefore there is no need to answer this email out of your office hours.* > > -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/>*Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours. <https://mojo.redhat.com/docs/DOC-1199578>*

2 1

This update's test gating status has been changed to, 'greenwave_failed'.
by Miro Hrončok 13 Jan '20

13 Jan '20

Couple of my updates have e-mailed me $subj. Is it something to worry about? Example: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f2ffe568a1 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

6 7

Fedora 32 System-Wide Change proposal: Firewalld Default to nftables
by Ben Cotton 06 Jan '20

06 Jan '20

https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables == Summary == This change will toggle the default firewalld backend from iptables to nftables. All of firewalld's primitives will use nftables while direct rules continue to use iptables/ebtables. == Owner == * Name: [[User:erig0| Eric Garver]] * Email: egarver(a)redhat.com == Detailed Description == Firewalld upstream has used nftables as the default backend for the past two minor releases. It is also the default in other distributions (e.g. RHEL-8). This change will bring Fedora in line with upstream. Using nftables bring many advantages. See firewalld's upstream [https://firewalld.org/2018/07/nftables-backend blog post]. It also highlights a few behavioral changes. == Benefit to Fedora == * Fewer firewall rules (rule consolidation) All of firewalld's primitives will use the same underlying firewall (nftables) instead of duplicating rules both in iptables and ip6tables. In nftables rules can match both IPv4 and IPv6 packets. This reduces the number of firewall rules by half. * firewalld's rules are namespaced With nftables firewalld's rules are isolated to a "firewalld" table. A separate firewall (or user) can create its own independent ruleset and firewalld will never touch it. * Netfilter upstream is focusing on nftables, not iptables == Scope == * Proposal owners: firewalld (erig0, Eric Garver) Currently the firewalld package has a Fedora downstream patch to hide the nftables backend. The only firewalld change required is to remove that patch from the package and rebuild. * Other developers: libvirt, podman, docker ** libvirt *** libvirt already cooperates with the firewalld nftables backend. The only thing needed is to test/verify. ** podman *** libvirt already cooperates with the firewalld nftables backend. The only thing needed is to test/verify. ** docker *** Docker currently does not cooperate with the nftables backend. It currently side-steps firewalld by injecting its own rules in iptables ahead of firewalld's rules. However, with the nftables backend firewalld's rule will still be evaluated. Netfilter in the kernel will call iptables, then nftables for the same packet. This means firewalld/nftables is likely to drop the packet even if docker has iptables rules to ACCEPT. *** Proposed fix 1: Docker package should provide a firewalld zone definition that includes the docker interfaces (e.g. docker0). The zone should use the "ACCEPT" policy (firewalld --set-target). This will allow docker's traffic to pass through firewalld/nftables. **** Issue 1: If a user has configured a different docker bridge name, then they'll have to manually add the bridge to the docker zone (or firewalld's trusted zone). *** Proposed fix 2: Just like "Proposed fix 1", but instead of adding the zone definition to docker we created a "docker-firewalld" (or firewalld-docker?) package that has the zone definition. This could be installed by default when docker is installed. * Policies and guidelines: No updated needed. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == When users are upgraded to firewalld with nftables enabled (f32) all their firewall rules will exist in nftables instead of iptables. All of firewalld's primitives (zones, services, ports, rich rules, etc.) are 100% compatible between backends. Users of direct rules may need to consider the [https://firewalld.org/2018/07/nftables-backend behavioral changes] that were announced upstream. Some are also highlighted here: * direct rules execute before _all_ firewalld rules ** This has been requested by users * packets dropped in iptables (or direct rules) will never be seen by firewalld * packets accepted in iptables (or direct rules) are still subject to firewalld's rules == How To Test == Testing should mostly be integration based. Firewalld upstream has a fairly comprehensive testsuite that covers functional testing. The following are packages known to integrate with firewalld. They should be tested with the nftables backend. * libvirt ** verify VMs with different network types (bridged, routed) have working network access ** newer version of libvirt should create and use a "libvirt" firewalld zone. Interfaces should be dynamically added to the zone. * podman ** verify podman adds container bridge interface to the "trusted" zone ** verify container still has network access * docker ** known to not work with the firewalld nftables backend out of the box ** verify new package docker-firewalld installs firewalld docker zone and has "docker0" interface added ** verify container still has network access * fail2ban-firewalld ** verify the direct rules added to firewalld by fail2ban still block traffic == User Experience == In general users shouldn't notice the change. Occasional a user will look at the iptables rule that firewalld generates. They'll now have to look at nftables instead. == Dependencies == * libvirt >= 5.1.0 * CNI >= 0.8.0 (used by podman) * docker-firewalld (new package) == Contingency Plan == * Contingency mechanism: firewalld maintainer (erig0) will reinstate the current patch to default to the iptables backend. * Contingency deadline: beta freeze == Documentation == * [https://firewalld.org/2018/07/nftables-backend Firewalld blog post] -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

5 5

Orphaning pykka
by Jonathan Dieter 05 Jan '20

05 Jan '20

I've just orphaned pykka (https://admin.fedoraproject.org/pkgdb/package /rpms/pykka/) as I'm no longer using it. Jonathan

3 4

Orphaned packages looking for new maintainers (incl. wine, dosbox, nextcloud, owncloud)
by Miro Hrončok 04 Jan '20

04 Jan '20

The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via releng issues: https://pagure.io/releng/issues Full report available at: https://churchyard.fedorapeople.org/orphans-2019-11-06.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change ================================================================================ FUR orphan 0 weeks ago WindowMaker orphan 0 weeks ago WindowMaker-extra orphan 0 weeks ago airsnort orphan 0 weeks ago apache-mime4j orphan 2 weeks ago aterm orphan 0 weeks ago base64coder jcapik, mizdebsk, orphan 0 weeks ago batik jvanek, mizdebsk, orphan 0 weeks ago bibus orphan 2 weeks ago bubblemon orphan 0 weeks ago castor-maven-plugin orphan 5 weeks ago classmate lef, orphan 0 weeks ago cli-parser lef, orphan 0 weeks ago diffuse cicku, fab, orphan 4 weeks ago dillo aarem, orphan 0 weeks ago dosbox fcami, orphan 0 weeks ago dynamite orphan 0 weeks ago eclipse-abrt orphan, sopotc 1 weeks ago eclipse-cdt akurtakov, eclipse-sig, 1 weeks ago jjohnstn, kdaniel, orphan, rgrunber eclipse-epp-logging orphan, sopotc 1 weeks ago eclipse-launchbar eclipse-sig, orphan, sopotc 1 weeks ago extra166y orphan 2 weeks ago fbdesk orphan 0 weeks ago felix-osgi-foundation orphan 2 weeks ago freealut jwrdegoede, orphan, pwalter 0 weeks ago glassfish-gmbal orphan 0 weeks ago glassfish-management-api orphan 0 weeks ago glassfish-pfl orphan 0 weeks ago gnu-regexp dbhole, mizdebsk, orphan 5 weeks ago grizzly orphan 0 weeks ago grizzly-npn orphan 0 weeks ago ht orphan 0 weeks ago isight-firmware-tools jmontleon, orphan 2 weeks ago jackson-dataformat-xml dchen, lef, orphan 0 weeks ago jandex-maven-plugin lef, orphan 0 weeks ago java-oauth lef, orphan 0 weeks ago jboss-connector-1.6-api gil, lef, orphan 0 weeks ago jboss-jaspi-1.1-api lef, orphan 0 weeks ago jboss-jsp-2.3-api orphan 0 weeks ago jcsp orphan 2 weeks ago jersey dchen, gwei3, orphan 0 weeks ago js-excanvas nodejs-sig, orphan, rathann, 5 weeks ago williamjmorenor json_diff orphan 4 weeks ago lcms ajax, alexl, caillon, caolanm, 0 weeks ago gnome-sig, johnp, mbarnes, orphan, rhughes, rstrode, ssp leafnode orphan 4 weeks ago libAfterImage ellert, orphan 0 weeks ago libdockapp orphan 0 weeks ago libetpan orphan, simo 0 weeks ago libfixposix orphan 5 weeks ago libktorrent kde-sig, liquidat, nucleo, 2 weeks ago orphan, rdieter, tuxbrewr libmimedir orphan 0 weeks ago libnxml orphan 0 weeks ago libodb-boost daveisfera, orphan 4 weeks ago libodb-qt daveisfera, orphan 4 weeks ago libopensync-plugin-evolution2 mcrha, orphan 0 weeks ago libopensync-plugin-file orphan 0 weeks ago libopensync-plugin-gpe orphan 0 weeks ago libopensync-plugin-moto orphan 0 weeks ago libopensync-plugin-opie orphan 0 weeks ago libopensync-plugin-synce orphan 0 weeks ago libpolyxmass orphan 0 weeks ago libpqxx daveisfera, orphan, rdieter 0 weeks ago libsynce orphan 0 weeks ago libutempter alexl, caillon, caolanm, gnome- 0 weeks ago sig, johnp, mbarnes, mlichvar, orphan, rhughes, rstrode, tkorbar menulibre orphan 3 weeks ago mimepull java-sig, lef, orphan 0 weeks ago mingw-wine-gecko mooninite, orphan 0 weeks ago msynctool orphan 0 weeks ago multiverse orphan 2 weeks ago mustache-java dchen, lef, mizdebsk, orphan 0 weeks ago ncmpc orphan 0 weeks ago netty3 jerboaa, lef, orphan 0 weeks ago nextcloud jhogarth, orphan, siwinski 0 weeks ago nfspy orphan 4 weeks ago nodejs-flot nodejs-sig, orphan, rathann, 5 weeks ago vjancik, williamjmorenor notify-python orphan 6 weeks ago openal-soft fcami, jwrdegoede, orphan 0 weeks ago orange orphan 0 weeks ago owncloud adamwill, ignatenkobrain, 0 weeks ago jhogarth, kwizart, orphan, siwinski parboiled mizdebsk, orphan 0 weeks ago pdfbox java-sig, orphan 0 weeks ago pegdown mizdebsk, orphan 5 weeks ago perl-Tk orphan, tremble, xavierb 0 weeks ago picketbox gil, lef, orphan 0 weeks ago picketbox-commons gil, lef, orphan 0 weeks ago picketbox-xacml gil, lef, orphan 0 weeks ago plexus-cli mizdebsk, orphan 2 weeks ago pypoppler orphan 4 weeks ago python-arc orphan 3 weeks ago python-httplib2 abompard, dchen, jspaleta, 0 weeks ago kevin, orphan python-ripozo churchyard, orphan, python-sig 2 weeks ago python-unittest2 aviso, bkabrda, carlwgeorge, 4 weeks ago churchyard, mbacovsk, orphan, pjp, python-sig, sundaram, ttorling qiv orphan 0 weeks ago rubygem-minitest-reporters orphan 0 weeks ago rxjava orphan, rfenkhuber 0 weeks ago rxvt orphan 0 weeks ago simple orphan 0 weeks ago slrn orphan 4 weeks ago synce-gnomevfs orphan 0 weeks ago synce-software-manager orphan 0 weeks ago synce-trayicon orphan 0 weeks ago system-config-httpd orphan, pknirsch 4 weeks ago treecc orphan 0 weeks ago unshield orphan 0 weeks ago vim-vimoutliner orphan 1 weeks ago virtio-forwarder orphan 3 weeks ago wine besser82, mooninite, orphan 0 weeks ago wine-docs orphan 0 weeks ago wine-mono mooninite, orphan 0 weeks ago wmCalClock orphan 0 weeks ago wmacpi orphan 0 weeks ago wmapmload orphan 0 weeks ago wmdocker orphan 0 weeks ago wmweather+ orphan 0 weeks ago yaws orphan 3 weeks ago The following packages require above mentioned packages: See https://churchyard.fedorapeople.org/orphans-2019-11-06.txt Grep it for your username and follow the dependency chain. Affected (co)maintainers aarem: dillo ablu: openal-soft abompard: python-unittest2, pdfbox, python-httplib2 achernya: libutempter adamwill: owncloud, python-unittest2 adrian: libutempter affix: libutempter ajax: lcms akurtakov: batik, eclipse-cdt, eclipse-launchbar, java-oauth alexl: libutempter, lcms alexlan: perl-Tk amigadave: openal-soft anishpatil: python-httplib2 ankursinha: js-excanvas, nodejs-flot anvil: pdfbox apevec: python-unittest2, python-httplib2 arobinso: java-oauth, castor-maven-plugin, eclipse-launchbar, batik, eclipse-cdt astro-sig: pdfbox athoscr: python-unittest2 atim: pdfbox aviso: python-unittest2 balajig8: libutempter bellet: openal-soft, freealut benc: pdfbox besser82: wine, openal-soft, wine-mono, mingw-wine-gecko bkabrda: python-unittest2 bonzini: pdfbox, libutempter bookwar: openal-soft bpepple: openal-soft brendt: lcms brouhaha: batik brummbq: libutempter bruno: openal-soft, freealut, python-httplib2 bsjones: mingw-wine-gecko, perl-Tk, wine-mono, wine caillon: libutempter, lcms caolanm: libutempter, lcms carlwgeorge: python-unittest2 certbot-sig: python-httplib2 chandankumar: python-httplib2 cheese: openal-soft, freealut cheeselee: pdfbox, libutempter chkr: python-httplib2 churchyard: python-ripozo, python-unittest2, python-httplib2 chwilk: openal-soft cicku: batik, pdfbox, diffuse cjatherton: lcms clalance: python-httplib2 comzeradd: libutempter corsepiu: openal-soft cqi: python-unittest2, python-httplib2 cquad: jboss-jsp-2.3-api ctubbsii: netty3 cwickert: pdfbox, libetpan, dillo daveisfera: libodb-boost, libpqxx, perl-Tk, libodb-qt, python-httplib2 davidcl: batik, pdfbox dbhole: java-oauth, gnu-regexp, eclipse-launchbar, batik, eclipse-cdt dcallagh: python-unittest2 dcantrel: libutempter dchen: glassfish-management-api, grizzly, jackson-dataformat-xml, mustache-java, mimepull, grizzly-npn, jersey, cli-parser, glassfish-gmbal, rxjava, glassfish-pfl, simple, python-httplib2 decathorpe: batik, pdfbox, rubygem-minitest-reporters deji: libutempter design-sw: openal-soft, freealut dormouse: python-httplib2 dtimms: openal-soft duffy: lcms dustymabe: python-unittest2 dvratil: batik, pdfbox, libutempter ebaron: batik, eclipse-cdt, eclipse-launchbar, java-oauth eclipse-sig: grizzly, java-oauth, gnu-regexp, mustache-java, eclipse-epp-logging, mimepull, grizzly-npn, cli-parser, eclipse-launchbar, glassfish-gmbal, jersey, glassfish-pfl, rxjava, batik, simple, eclipse-cdt, glassfish-management-api eclipseo: openal-soft, pdfbox eischmann: pdfbox ekulik: mingw-wine-gecko, wine, wine-mono ellert: libAfterImage elsupergomez: pdfbox elwell: python-unittest2 elyscape: python-httplib2 eseyman: perl-Tk f1ash: pdfbox fab: perl-Tk, python-unittest2, diffuse fale: python-unittest2 fcami: openal-soft, dosbox filabrazilska: perl-Tk filiperosset: perl-Tk, libutempter fivaldi: python-httplib2 frantisekz: mingw-wine-gecko, wine, wine-mono, rubygem-minitest-reporters fredlima: openal-soft gbcox: pdfbox germano: pdfbox gholms: python-unittest2 giallu: batik gil: jboss-connector-1.6-api, java-oauth, picketbox-xacml, picketbox-commons, jboss-jaspi-1.1-api, picketbox gilboa: openal-soft gnome-sig: libutempter, lcms golfu: pdfbox greghellings: python-unittest2, netty3 guidograzioli: openal-soft gwei3: grizzly, mustache-java, mimepull, grizzly-npn, cli-parser, jersey, glassfish-gmbal, rxjava, glassfish-pfl, simple, glassfish-management-api hanecak: lcms hardaker: perl-Tk hedayat: pdfbox, python-httplib2 heliocastro: batik, pdfbox herlo: python-unittest2 hguemar: python-unittest2, python-httplib2 hhorak: pdfbox hobbes1069: openal-soft, freealut, perl-Tk hpejakle: libutempter hubbitus: mustache-java, freealut, openal-soft, cli-parser, netty3 hvad: perl-Tk iarnell: perl-Tk icon: batik, pdfbox ignatenkobrain: owncloud, openal-soft, python-unittest2, freealut ignotusp: libutempter imcleod: python-httplib2 infra-sig: python-httplib2 ishcherb: python-httplib2 itamarjp: openal-soft, pdfbox, libutempter jackorp: rubygem-minitest-reporters jamesni: python-httplib2 jamielennox: python-httplib2 jaruga: rubygem-minitest-reporters java-sig: mimepull, pdfbox jcapik: base64coder jcline: python-unittest2, libpqxx jdieter: openal-soft jerboaa: java-oauth, eclipse-launchbar, netty3, batik, eclipse-cdt jfearn: batik, pdfbox jgrulich: openal-soft, pdfbox, libutempter jhogarth: owncloud, nextcloud jima: perl-Tk jjelen: jboss-jsp-2.3-api jjg: libutempter jjohnstn: grizzly, java-oauth, mustache-java, mimepull, grizzly-npn, cli-parser, eclipse-launchbar, glassfish-gmbal, jersey, glassfish-pfl, rxjava, batik, simple, eclipse-cdt, glassfish-management-api jkaluza: python-httplib2 jlayton: openal-soft jmontleon: isight-firmware-tools johnp: libutempter, lcms jorton: libutempter jpena: python-unittest2 jplesnik: perl-Tk jpopelka: python-httplib2 jraber: pypoppler jreznik: openal-soft, pdfbox, libutempter jridky: perl-Tk jruzicka: python-httplib2 jsafrane: perl-Tk jspaleta: pypoppler, python-httplib2 jsynacek: openal-soft jujens: python-unittest2 julian: openal-soft jvanek: mustache-java, pdfbox, cli-parser, netty3, batik jwrdegoede: dynamite, openal-soft, freealut karlik: openal-soft karsten: pdfbox kdaniel: eclipse-cdt, eclipse-launchbar, java-oauth kde-sig: libktorrent, openal-soft, pdfbox, libutempter, batik kevin: python-httplib2 kkofler: pdfbox, libutempter krege: mingw-wine-gecko, wine, pdfbox, libutempter, wine-mono kumarpraveen: python-unittest2 kwizart: libpqxx, freealut, openal-soft, pdfbox, perl-Tk, owncloud kzak: libutempter larsks: python-unittest2 laxathom: openal-soft lbalhar: pdfbox lbazan: python-unittest2, mustache-java, cli-parser, netty3, libutempter lef: jboss-connector-1.6-api, eclipse-cdt, jboss-jsp-2.3-api, java-oauth, jackson-dataformat-xml, mustache-java, jandex-maven-plugin, picketbox-xacml, jboss-jaspi-1.1-api, mimepull, picketbox-commons, cli-parser, classmate, picketbox, netty3, eclipse-launchbar, batik, castor-maven-plugin liangsuilong: pdfbox limb: openal-soft, pdfbox, freealut, python-httplib2 linkdupont: openal-soft liquidat: pdfbox, libktorrent, libutempter lkundrak: batik, pdfbox, perl-Tk lsedlar: python-unittest2, python-httplib2 lucilanga: perl-Tk lupinix: pdfbox luya: openal-soft, freealut magnu5: libutempter marcdeop: pdfbox, libutempter marionline: pdfbox martinkg: openal-soft, freealut mattia: pdfbox maxamillion: perl-Tk, pdfbox, rubygem-minitest-reporters mbacovsk: python-unittest2 mbaldessari: python-httplib2 mbarnes: libutempter, lcms mbooth: java-oauth, gnu-regexp, eclipse-epp-logging, eclipse-launchbar, batik, eclipse-cdt mbriza: pdfbox, libutempter mck182: pdfbox mcrha: libopensync-plugin-evolution2, libutempter melmorabity: pdfbox, notify-python mfrodl: python-httplib2 mhayden: python-unittest2 mich181189: pdfbox minh: pdfbox, libutempter misc: python-httplib2 mizdebsk: java-oauth, base64coder, gnu-regexp, mustache-java, pdfbox, cli-parser, eclipse-launchbar, parboiled, pegdown, plexus-cli, batik, eclipse-cdt mkyral: pdfbox, libutempter mlichvar: libutempter mluscon: netty3 mmahut: python-unittest2 mmorsi: python-httplib2 mmraka: jboss-jsp-2.3-api moceap: pdfbox mooninite: mingw-wine-gecko, wine, wine-mono, openal-soft mpreisle: openal-soft, freealut mrunge: python-unittest2, python-httplib2 mschwendt: libetpan, dillo mtasaka: rubygem-minitest-reporters, libetpan, libutempter musuruan: pdfbox mystro256: openal-soft nb: pdfbox, python-httplib2 nbecker: pdfbox neuro-sig: js-excanvas, nodejs-flot, python-unittest2 ngompa: nodejs-flot, js-excanvas, python-unittest2, openal-soft, pdfbox, batik, python-httplib2 nguzman: eclipse-cdt, eclipse-launchbar, java-oauth nodejs-sig: js-excanvas, nodejs-flot nonamedotc: pdfbox nphilipp: perl-Tk nucleo: pdfbox, libktorrent, libutempter odubaj: classmate ohaessler: openal-soft oliver: batik, eclipse-cdt, eclipse-launchbar, java-oauth onosek: python-unittest2 openstack-sig: python-httplib2 orion: java-oauth, pdfbox, eclipse-launchbar, libutempter, batik, eclipse-cdt patches: batik pcpa: openal-soft peter: batik, pdfbox petersen: openal-soft, freealut pghmcfc: python-httplib2, perl-Tk, libutempter pgordon: pypoppler pingou: python-unittest2 pjp: python-unittest2, python-httplib2 pknirsch: system-config-httpd plfiorini: pdfbox pmackinn: base64coder pnemade: python-httplib2 ppisar: perl-Tk pranvk: openal-soft psss: python-httplib2 pvalena: rubygem-minitest-reporters pwalter: openal-soft, freealut, lcms pwu: pdfbox python-sig: nodejs-flot, js-excanvas, python-unittest2, python-ripozo, python-httplib2 qulogic: js-excanvas, nodejs-flot qwan: python-httplib2 ralph: python-unittest2, python-httplib2 raorn: libdockapp raphgro: mingw-wine-gecko, wine, pdfbox, wine-mono rathann: js-excanvas, nodejs-flot, libutempter rdieter: libktorrent, libpqxx, openal-soft, pdfbox, libutempter, batik rfenkhuber: rxjava rgrunber: grizzly, java-oauth, mustache-java, mimepull, grizzly-npn, cli-parser, eclipse-launchbar, glassfish-gmbal, jersey, glassfish-pfl, rxjava, batik, simple, eclipse-cdt, glassfish-management-api rhughes: pdfbox, libutempter, lcms rjones: perl-Tk rlandmann: batik, pdfbox rmarko: python-unittest2 rmattes: openal-soft, libpqxx, freealut rmyers: eclipse-cdt, eclipse-launchbar, java-oauth rnovacek: pdfbox robotics-sig: openal-soft, libpqxx robyduck: python-httplib2 roma: openal-soft, freealut rstrode: libutempter, lcms ruby-packagers-sig: rubygem-minitest-reporters s4504kr: openal-soft, pdfbox, freealut sagitter: openal-soft, python-unittest2, freealut sailer: libpqxx salimma: python-unittest2, pdfbox, libutempter scenek: perl-Tk seanf: python-httplib2 sergiomb: pdfbox sharkcz: openal-soft, freealut siddharths: pdfbox, libutempter simo: libetpan siwinski: owncloud, nextcloud skottler: pdfbox, netty3 slaanesh: openal-soft, freealut slankes: pdfbox, libutempter smani: pdfbox, libutempter sonkun: openal-soft sopotc: java-oauth, eclipse-abrt, eclipse-epp-logging, eclipse-launchbar, eclipse-cdt spot: openal-soft, freealut, python-httplib2, perl-Tk ssp: libutempter, lcms stahnma: rubygem-minitest-reporters stefanb: batik, pdfbox steve: openal-soft stevetraylen: openal-soft, freealut stransky: openal-soft, freealut strobert: libutempter suanand: python-httplib2 sundaram: python-unittest2, python-httplib2 suve: openal-soft svahl: pdfbox, libutempter tc01: mingw-wine-gecko, wine, openal-soft, pdfbox, wine-mono tdawson: rubygem-minitest-reporters tejas: pdfbox terjeros: batik, pdfbox, libutempter than: openal-soft, pdfbox, libutempter thias: openal-soft, freealut thm: mingw-wine-gecko, wine, wine-mono thomasfedb: python-httplib2 thozza: batik tibbs: pdfbox till: perl-Tk timn: libpqxx tkorbar: libutempter tnorth: pdfbox tremble: perl-Tk tstclair: netty3 ttorling: python-unittest2, libpqxx tuxbrewr: pdfbox, libktorrent, libutempter uraeus: openal-soft vascom: pdfbox, libutempter vdolezal: libutempter vjancik: nodejs-flot, pdfbox, js-excanvas vladimirk: eclipse-cdt, eclipse-launchbar, java-oauth volter: python-httplib2 vondruch: rubygem-minitest-reporters williamjmorenor: js-excanvas, nodejs-flot wolnei: pdfbox wtaymans: openal-soft xavierb: perl-Tk yograterol: python-unittest2 zbyszek: mustache-java, cli-parser, netty3 zdohnal: perl-Tk -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its pagure instance: https://pagure.io/releng/ The sources of this script can be found at: https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

10 16

systemd 244-rc1
by Zbigniew Jędrzejewski-Szmek 21 Dec '19

21 Dec '19

Hi, a new systemd has been sent to rawhide. I don't expect any major trouble, but please report any issues. Quoting %changelog: Biggest items: cgroups v2 cpuset controller, fido_id builtin in udev, systemd-networkd does not create a default route for link local addressing, systemd-networkd supports dynamic reconfiguration and a bunch of new settings. Network files support matching on WLAN SSID and BSSID. ... or in other words: networkctl reload, networkctl renew, networkctl reconfigure wlan0. I think this is pretty nice functionality for networkd users on the desktop. This version has support for disabling watchdogs at configuration time for services bundled with systemd. I want to do that in Fedora, because almost all "crash" reports that we get are about the watchdog firing on resource starvation, which is not good, but having the watchdog terminate the process has very little benefit for the users, and spams bugzilla with useless reports. I didn't actually disable the watchdogs yet, but I'll plan to do it on Monday if the version that was built now seems OK. For full NEWS, see https://github.com/systemd/systemd/blob/master/NEWS#L3. Zbyszek

2 2

Paul Grosu
by Paul Grosu 17 Dec '19

17 Dec '19

Hello Fedora Development Community, I work at Northeastern University as a researcher in the Gene Cooperman Lab, and will be supporting the DMTCP package ( https://apps.fedoraproject.org/packages/dmtcp) and DMTCP-devel ( https://apps.fedoraproject.org/packages/dmtcp-devel) We are about to release a new version of the package but don't have a aarch-64 machine, and was wondering how to go about having access to one of the test machines listed on the following weblink: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintaine… Please let me know how to proceed regarding getting access to a test machine. Thank you, Paul

4 10

Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
by Ben Cotton 13 Dec '19

13 Dec '19

https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault == Summary == Remove ''nullok'' parameter from pam_unix module in default PAM configuration in order to disallow authentication with empty password. == Owner == * Name: [[User:pbrezina| Pavel Březina]] * Email: <pbrezina(a)redhat.com> == Detailed Description == Current default configuration allows users to login with an empty password by setting nullok parameter to pam_unix module. This affects only logins to local machine, it does not affect ssh logins as this must be explicitly allowed in sshd_config. We want to disallow empty password by default for local logins as well to improve system hardening. Note: It is possible to disallow empty passwords with authselect call (authselect enable-feature without-nullok) or by removing nullok manually, however it creates possible issues in other components that must be addressed. === Affected Components === * '''passwd''' - calling passwd -d to remove users password must be denied if empty passwords are disallowed otherwise the user will be locked out of the system * '''AccountService''' - D-Bus methods ''SetPassword'' and ''SetPasswordMode'' on ''org.freedesktop.Accounts.User'' interface can remove user’s password and lock the user out of the system if empty password is disallowed. These calls must be denied in this case. Additionally, these methods can be run by normal users as opposed to ''passwd -d'' and ''chage -d 0'' which can be run only by root. Therefore only root should be able to call these methods. * '''Gnome’s Control Center''' - when creating new users, it provides an option to “require password to be set on first login” which creates user with expired empty password. This would again lock the user out of the system. * '''Other Desktop Environments''' - may have the same issue as Gnome Control Center === Solution Step by Step === ==== Step 1) Provide a unified way to read if nullok is enabled or not ==== We will create an authselect library call that would parse existing PAM configuration (not necessarily generated by authselect) and return list of enabled/disabled features. We will implement only ''nullok'' feature in the scope of this change but if needed it can be extended in the future. ==== Step 2) Fix passwd -d ==== Calling ''passwd -d'' to remove user's password will fail if ''nullok'' is disabled. ==== Step 3) Fix AccountService ==== These methods on ''org.freedesktop.Accounts.User'' D-Bus interface will be callable only by ''root'' and must return an error if ''nullok'' is disabled. SetPasswordMode SetPassword(“”, hint) ==== Step 4) Fix Desktop Environments ==== “Require password change on next login” must keep working. This feature currently relies on setting an empty password. A new option ''nullresetok'' will be implemented for ''pam_unix'' module that will allow user to authenticate with empty password only if a password change for this user is enforced upon login. Authentication with empty passwords which are not expired will be prohibited (unless ''nullok'' is set). ==== Step 5) Update PAM configuration to disable nullok by default ==== In authselect and pam components for new installations. Upgrading from older systems will keep nullok present. == Benefit to Fedora == Changes in described components (Step 1 - Step 4) are necessary to implement in order to make sure that user accounts and tools works correctly when authentication with empty password is disabled by system administrator. Changing system default to disallow authentication with empty passwords (Step 5) improves system hardening. == Scope == * Proposal owners: Coordinate the work. Make sure all required changes are implemented. * Other developers: All affected component must be fixed. Changes are described in ''Detailed Description'' * Release engineering: [https://pagure.io/releng/issue/9038 #9038] (a check of an impact with Release Engineering is needed)   * Policies and guidelines: No updates needed. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This does not affect system upgrades because only new installation will have changed default. == How To Test == * Calling ''passwd -d user'' as root must fail with default configuration. * Calling ''org.freedesktop.Accounts.User.SetPassword("", hint)'' and ''org.freedesktop.Accounts.User.SetPasswordMode(x)'' must fail with default configuration. * "require password reset on first login" must keep working when creating users from Desktop Environment's GUI tools == User Experience == Users will no longer be able to use empty passwords by default. == Dependencies == None. == Contingency Plan == * Contingency mechanism: Default behavior will not be changed. * Contingency deadline: Beta * Blocks release? No * Blocks product? No == Documentation == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

28 194

Modularity: The Official Complaint Thread
by Stephen Gallagher 11 Dec '19

11 Dec '19

Last week, I put out a blog post and fedora-devel thread describing the problems that we wanted to solve with Modularity. That thread was not ultimately as successful as I had hoped. My intention was to provide some scope to the problem, because it seemed that a lot of alternatives being floated were not seeing some of the more subtle cases that we were trying to address. However, the biggest problem is that nearly every email to the list has been started with a "Begging the Question" Fallacy. People have started from the premise that "Modularity is Bad" and all of the rest of the conversation has continued from there. I'd like to provide an opportunity for us as a community to *constructively* state our grievances with Modularity. The fundamental root cause of some of the miscommunication is, I believe, that Modularity has problems and that people have assumed that they are fundamental and unfixable. I'd like to gather a constructive list of the actual use-cases that you feel Modularity is causing problems for, with the following stipulations: Any *subjective* problems will be ignored. "I think writing YAML is harder than writing a spec file" is an example of a subjective opinion. Similarly, "change inevitably results in some learning curve" is a basic maxim of innovation and is not in and of itself an argument not to change. "Modularity requires me to write both a spec file and a YAML file, thereby increasing the total work" is an *objective* observation (and a valid one; I'm going to include it below in my own starter list). If you aren't sure if it's objective, a useful question is "is it quantitatively measurable?" (AKA "Can I assign a number to it and see that number increase or decrease when changing something about the implementation?") So, in the interest of highlighting some specific cases where the current, deployed[1] implementation (in no particular order): 1. Once enabled, a module stream is never changed on behalf of the user. While this adds some strong guarantees to those who want to run applications built from those streams, the presence of default streams changes the expected upgrade behavior for users. Traditionally, at upgrade a user would get the new release's most-updated version of all packages currently on their system. With Modularity, if one of their packages comes from a default stream and that stream is not the default for the next release, they will stay on the current stream (or be blocked from upgrading, if the current stream is unavailable on the next release). [2] 2. Packages moved out of traditional Fedora and into a default module stream are not available to the non-modular buildroot. [3] 3. Insufficient guidelines and rules have resulted in some modules being shipped in a state that makes it difficult or impossible to build other software for the distribution. In particular, the 'ant' and 'maven' modules have default streams that own the namespace of several of their dependencies that have been configured for private use rather than public to the rest of the distrtibution. [4] 4. Documentation of how to create a module stream is comprehensive but daunting. There is a lot of available information, but what is really lacking is a basic walkthrough for converting a single package to a module stream. 5. There is no specification defined for dropping a default or enabled module stream and returning to non-modular packages. 6. We don't provide a direct solution for parallel-installability. This is an intentional design decision, but it *is* arguably a regression from SCL functionality, so I'll include it here. 7. The implementation in DNF occurs in libdnf rather than at the libsolv layer, which makes it difficult to reimplement for other packaging or build tools (such as GNOME Software and OBS, resp.) 8. The YAML format for modulemd is complex and can be difficult to get started with. [5] [6] 9. We don't have a good document on how to MBS generates modules and their repositories. This makes it hard for other build-systems to replicate the behavior. [7] 10. The MBS has performance issues which make official builds take a long time. [8] 11. "Module Stream API" when used in a default stream causes package incompatibilities and unsupportable configurations. [4] 12. Packaging a module requires writing both a spec file and a modulemd YAML file, which increases the total amount of work I need to do. [5] I'm sure there are other pain points and I encourage you to share them. Please adhere to the guidelines about objectively measurable issues, though. --- [1] I'll highlight with a [N] any of the cases I list that have a non-deployed fix, mitigation or are under design. [2] This is an identified user-experience issue and is under active design discussion on other threads. Please do not rehash that here. Some of the options being considered are: - Record whether the user "locked" themselves on a stream or had it enabled because it happened to be the default stream and they installed a package from it. - Add new metadata for the streams: "Upgrades:" and "Obsoletes:". - Drop support for default streams in Fedora 32, moving all content in default streams back into the non-modular space. [3] We have an initiative (not a service) called "Ursa Prime" which is essentially a pungi config that imports the modular repo into the buildroot and relies on mock using DNF correctly to pull in the appropriate packages from default streams (meaning it will work on local mock builds as well as Koji builds so long as we modify the mock repo config to include the modular repos). This is in contrast to the original "Ursa Major" project that would have been a separate service in Fedora Infrastructure dedicated to tagging the artifacts from a specific set of module streams into the buildroot tags. "Ursa Prime" is ready and could be deployed at any moment, pending FESCo approval of https://pagure.io/fesco/issue/2255 [4] The Modularity WG and FESCo agreed a few weeks ago that if any module stream is shipped as a default, all of its artifacts must conform to the same behavior as expected of a package shipped in the traditional manner. This also means that as part of the Fedora 32 process, we would need to go through any default streams and ensure that they are in compliance or remove their default stream until they are. [5] We have a tool called `fedmod` that has a command `rpm2module` that does a lot of the bootstrapping work but that no one seems to know about. [6] I've proposed a backwards-compatible 'modulemd-packager' YAML format that trims out the extra content that only the build-system uses and that the packager could ignore. See https://github.com/fedora-modularity/libmodulemd/issues/364 [7] I wrote a blog post on how to generate module repositories without using MBS as a reference implementation: https://sgallagh.wordpress.com/2019/08/14/sausage-factory-modules-fake-it-t… [8] MBS is aware of this and is re-architecting its worker design to improve it. https://pagure.io/fm-orchestrator/issue/1311

28 134

← Newer
1
2
3
4
5
6
7
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2019