Re: Crypto policies packaging guideline
On 08/28/2014 08:55 AM, Vít Ondruch wrote: Dne 27.8.2014 22:42, James Antill napsal(a): #topic #452 Crypto policies packaging guideline .fpc 452 https://fedorahosted.org/fpc/ticket/452 Looking into this topic and the proposed guidelines [1], I am not sure how to apply them for Ruby. FPC discussed proposal briefly this during the meeting 2 weeks ago. AFAIR, we felt this proposal is beyond your knowledge and we feared this proposal to be inapplicable. IMHO, we need a crypto-expert or team to formally review this proposal, to identify packages it affects and to advise packagers and upstreams on how to implement this, because I feel this proposal is way beyond the scope of skill/knowledge of an average packager. That, said, I am not sure, this proposal should be made part of the FPG, but needs some kind of special treatment. Don't take me wrong, I support this effort. It just looks to have lot of blind spots. ACK. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fakesystemd package breaking builds
On Wed, Aug 27, 2014 at 11:01:45PM -0400, Rahul Sundaram wrote: > Hi > > > On Wed, Aug 27, 2014 at 10:05 PM, Simo Sorce wrote: > > > > > I think you are readying way to much into a perfectly normal word that > > means: "hey we are discussing stuff related to your project, would you > > mind joining this sessions so we can have better understanding ?" > > > > That's possible. The essential problem however is seemingly systemd > related package and additional components are being introduced apparently > without systemd developers being aware of that. That suggests that there > is a communication problem irrespective of the words used We were discussing this issue on systemd hackfest during Flock in person. Hence as for fakesystemd I don't think there was anything done behind anybodies back. On the other hand, I acknowledge that there maybe doubts and concerns about overall implementation. > > Rahul Michal > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fakesystemd package breaking builds
>>> It's a package that fakes systemd presence in system. It's solely >>> intended for Docker images as we don't want systemd there (at least >>> as long as it takes to prepare systemd-container Michal is working >>> on). I made a mistake and it ended up being pulled in buildroot. >>> >>> Ping me on IRC if you have more questions or comments. >> >> >> >> So what is "systemd-container" supposed to do? And what precisely is >> "fakesystemd" supposed to do? And that "mini" thing? > > fakesystemd owns same directories systemd does and has set provides to Surely the proper, at least standard, way of dealing with creation/ownership of a directory structure that's needed by other packages would be systemd-filesystem like so many other packages handle it (yes, I'm aware this is just one of the issues attempting to be addressed by the above package). Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] GNOME 3.14 Test Day today!
Hi, folks! Sorry for the late notice, but better late than never. Amita mentioned this on Tuesday, but I figured a proper announcement mail can't hurt! Today (that is, 2014-08-28) is GNOME Test Day! https://fedoraproject.org/wiki/Test_Day:2014-08-28_Gnome_3.14 We’ll be testing GNOME 3.14 pre-release on Fedora 21 pre-Alpha, so I expect everything will work absolutely perfectly and no-one will find any bugs at all ;) But seriously! Come on down and test, there are lots of fun new features in GNOME 3.14 to try and both GNOME and Fedora teams could definitely use some exercise on the new bits that’ll be included. We have brand-spanking-new nightly live images for i686 and x86_64, and even an ARM image if you’re that one person with hardware capable of running GNOME Shell on ARM. Wayland is actually in more-or-less usable shape for Intel video adapters now, so if you have an Intel-based system you can even give that a try! The wiki page has full instructions, and we’re using the handy test day results reporting system[1] so you don’t have to hand-edit results into wiki pages, that’s so 2012. Friendly folks – both QA folks and GNOME developers – will be standing by all day European and North American time in #fedora-test-day on Freenode IRC to help you out with testing and discuss any bugs you come across. If you don’t know how to use IRC, you can read the instructions[2], or just use WebIRC[3]. Please come by and help out if you have a few spare minutes! Thanks. 1. http://testdays.qa.fedoraproject.org/testdays/show_event?event_id=17 2. http://fedoraproject.org/wiki/How_to_use_IRC 3. http://webchat.freenode.net/?channels=fedora-test-day -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20140828 changes
Compose started at Thu Aug 28 07:15:03 UTC 2014 Broken deps for armhfp -- [APLpy] APLpy-0.9.8-5.fc21.noarch requires pywcs [PyKDE] PyKDE-3.16.6-14.fc20.armv7hl requires sip-api(10) >= 0:10.0 [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [couchdb] couchdb-1.6.0-9.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 couchdb-1.6.0-9.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [csound] csound-java-5.19.01-1.fc20.armv7hl requires libgcj_bc.so.1 csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-1.5.0-gcj csound-tk-5.19.01-1.fc20.armv7hl requires libtk8.5.so csound-tk-5.19.01-1.fc20.armv7hl requires libtcl8.5.so [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [docker-registry] docker-registry-0.7.3-1.fc21.noarch requires docker-io [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [ejabberd] ejabberd-2.1.13-8.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [elpa] elpa-openmpi-2013.11-4.008.fc21.armv7hl requires libmpi_usempi.so.1 [erlang-basho_metrics] erlang-basho_metrics-1.0.0-10.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-bitcask] erlang-bitcask-1.6.3-1.fc20.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-cl] erlang-cl-1.2.1-2.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-ebloom] erlang-ebloom-1.1.2-4.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-eleveldb] erlang-eleveldb-1.3.2-2.fc20.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-emmap] erlang-emmap-0-0.8.git05ae1bb.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-erlsyslog] erlang-erlsyslog-0.6.2-6.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-esasl] erlang-esasl-0.1-15.20120116git665cc80.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-esdl] erlang-esdl-1.3.1-3.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-js] erlang-js-1.2.2-5.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-sd_notify] erlang-sd_notify-0.1-1.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-skerl] erlang-skerl-1.1.0-7.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-snappy] erlang-snappy-1.0.3-0.7.git80db168.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flashrom] flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [ghc-hint] ghc-hint-devel-0.4.2.0-2.fc21.armv7hl requires ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc) [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.10.0-4.fc21.armv7hl requires libupower-glib.so.2 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [hibernate-search] hibe
Re: F-21 Branched report: 20140828 changes
On Thu, Aug 28, 2014 at 11:09:37AM +, Fedora Branched Report wrote: > Broken deps for armhfp > [libvirt] > libvirt-lock-sanlock-1.2.7-2.fc21.armv7hl requires sanlock >= 0:2.4 > libvirt-lock-sanlock-1.2.7-2.fc21.armv7hl requires > libsanlock_client.so.1 > Broken deps for i386 > -- > [libvirt] > libvirt-lock-sanlock-1.2.7-2.fc21.i686 requires sanlock >= 0:2.4 > libvirt-lock-sanlock-1.2.7-2.fc21.i686 requires libsanlock_client.so.1 A bogus ExclusiveArch restriction was added to the sanlock package preventing it building on armv7 and i686. Bug to request this be removed, which would fix libvirt deps: https://bugzilla.redhat.com/show_bug.cgi?id=1134861 Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fakesystemd package breaking builds
On 08/27/2014 03:15 PM, Lennart Poettering wrote: > On Wed, 27.08.14 21:00, Václav Pavlín (vpav...@redhat.com) wrote: > >>> I also offered to split out the hwdb in Brno, if you remember. If this >>> is about the hwdb, then let's just do that... >> Talk to Michal Sekletar about it then - he is working on "something" >> we call systemd-container internally. We need systemd running in >> Docker container. I don't like to have needless stuff in images but >> if the result is "just drop the hwdb" then I am fine with that. > As discussed in Brno, "not liking to have needless stuff around" alone > is really not a convincing reason. > > I mean, you could make the case for the size of things, but afaics this > doesn't hold any water here... kmod is a 150K dep, and the other stuff, > is that any bigger? For 150K we shouldn't complicate things this much... > > You could also make the case for the dependencies, but this is kind the > same as the size argument... > > And you could make the case for "security", but that's really wrong too, > since recent systemd versions have exactly zero suid binaries, and if > you don't run the daemons, then you have exactly zero ways to raise your > priviliges. And just having dead code lying around is not really an > issue. I mean, if you managed to exploit something and smuggled in some > code, then you smuggled in some code, why would make it any difference > if there's dead code lying around or not in the container? > >>> But regarding kmod/devicemapper, can we please get some stats about how >>> big this individually are, and how much is saved by this? kmod at least >>> is 150K or so only. Is there really any value in doing this weird stuff >>> for a fricking 150K?! Fedora has no bigger fishes to fry? >> I'll prepare stats for you tomorrow. >>> The systemd-container or fakesystemd stuff sounds awfully adhoc. Can we >>> please always discuss this first, and see if we can find a different >>> solution? We don't need three different "solutions", if one works >>> too... >> We've talked about this on Flock - it's not only about disk space >> but also about security reasons (CC'ing Dan Walsh). My goal was not > Dan, can you elaborate what the rationale for this is? It is not about Security escalation is is about the need to update a container image if a CVE happens on any of the packages installed. Basically we want to keep the turn on images as small as possible. If systemd, kmod, udev ... have a CVE and they are not used within an image, then we would still need to update the image because it containers "Vulnerable" code, or potentially vulnerable code. Fakesystemd was developed for RHEL/Centos images to help minimize the CVE footprint. This was discussed on on this fpc request. https://fedorahosted.org/fpc/ticket/425. I actually did not want fakesystemd to go into Fedora for exactly the fear of it screwing up builds. I like the idea of systemd-container, or some other minimal systemd environment which understands and works well within container, and am trying to get pull requests into docker to allow systemd to work well. https://github.com/docker/docker/pull/7685 https://github.com/docker/docker/pull/7685 If we got a good version of systemd-container, (Or systemd) which did not suck in other requirements an stopped other random rpm sucking in stuff not needed in container, I would be all for dropping fakesystemd. >> to have needless junk in base image - if we are not going to use >> systemd to manage services there, why should it be there with all >> it's dependencies? > This sounds awfully like a "just because!" reason... > > Lennart > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20140828 changes
Broken deps for i386 -- [0ad] 0ad-0.0.16-9.fc22.i686 requires libicuuc.so.52 0ad-0.0.16-9.fc22.i686 requires libicui18n.so.52 [APLpy] APLpy-0.9.8-5.fc21.noarch requires pywcs [PyKDE] PyKDE-3.16.6-14.fc20.i686 requires sip-api(10) >= 0:10.0 [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [aws] aws-devel-3.1.0-6.fc21.i686 requires libgrypt-devel [cduce] cduce-0.6.0-6.fc22.i686 requires ocaml(String) = 0:d3baab1cf7edc2fec1fa9c9217140d10 cduce-0.6.0-6.fc22.i686 requires ocaml(Pervasives) = 0:4329e57fde14cc94b02a739d2595516b cduce-0.6.0-6.fc22.i686 requires ocaml(Location) = 0:0beb1f904f757422c85ea51aae076559 cduce-0.6.0-6.fc22.i686 requires ocaml(Lazy) = 0:65801e9cdbd8c4e82df1f02f97116721 cduce-0.6.0-6.fc22.i686 requires ocaml(Format) = 0:a9de4c8c622e30d6eb221ce41563dbf4 cduce-0.6.0-6.fc22.i686 requires ocaml(Filename) = 0:3b889637b7a18c39de7a0d0f5d10432e cduce-0.6.0-6.fc22.i686 requires ocaml(Array) = 0:9125e0607c9ad02018c9eb4672142241 [compat-gcc-34] compat-gcc-34-c++-3.4.6-29.fc19.i686 requires libstdc++ < 0:4.9.0 [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so [couchdb] couchdb-1.6.0-11.fc22.i686 requires erlang(erl_nif_version) = 0:2.4 couchdb-1.6.0-11.fc22.i686 requires erlang(erl_drv_version) = 0:2.2 [cp2k] cp2k-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc22.i686 requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [csound] csound-java-5.19.01-1.fc20.i686 requires libgcj_bc.so.1 csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-1.5.0-gcj csound-tk-5.19.01-1.fc20.i686 requires libtk8.5.so csound-tk-5.19.01-1.fc20.i686 requires libtcl8.5.so [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [docker-registry] docker-registry-0.7.3-1.fc22.noarch requires docker-io [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [ejabberd] ejabberd-2.1.13-8.fc21.i686 requires erlang(erl_drv_version) = 0:2.2 [elk] elk-openmpi-2.3.22-7.fc21.i686 requires libmpi_usempi.so.1 [elpa] elpa-openmpi-2013.11-4.008.fc21.i686 requires libmpi_usempi.so.1 [erlang-basho_metrics] erlang-basho_metrics-1.0.0-11.fc22.i686 requires erlang(erl_nif_version) = 0:2.4 [erlang-bitcask] erlang-bitcask-1.6.3-1.fc20.i686 requires erlang(erl_nif_version) = 0:2.4 [erlang-cl] erlang-cl-1.2.1-3.fc22.i686 requires erlang(erl_nif_version) = 0:2.4 [erlang-ebloom] erlang-ebloom-1.1.2-5.fc22.i686 requires erlang(erl_nif_version) = 0:2.4 [erlang-eleveldb] erlang-eleveldb-1.3.2-5.fc22.i686 requires erlang(erl_nif_version) = 0:2.4 [erlang-emmap] erlang-emmap-0-0.9.git05ae1bb.fc22.i686 requires erlang(erl_nif_version) = 0:2.4 [erlang-erlsyslog] erlang-erlsyslog-0.6.2-6.fc22.i686 requires erlang(erl_drv_version) = 0:2.2 [erlang-esasl] erlang-esasl-0.1-15.20120116git665cc80.fc22.i686 requires erlang(erl_drv_version) = 0:2.2 [erlang-esdl] erlang-esdl-1.3.1-4.fc22.i686 requires erlang(erl_drv_version) = 0:2.2 [erlang-js] erlang-js-1.2.2-6.fc22.i686 requires erlang(erl_drv_version) = 0:2.2 [erlang-sd_notify] erlang-sd_notify-0.1-1.fc21.i686 requires erlang(erl_nif_version) = 0:2.4 [erlang-skerl] erlang-skerl-1.1.0-8.fc22.i686 requires erlang(erl_nif_version) = 0:2.4 [erlang-snappy] erlang-snappy-1.0.3-0.8.git80db168.fc22.i686 requires erlang(erl_nif_version) = 0:2.4 [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flashrom] flashrom-0.9.6.1-5.svn1705.fc20.i686 requires libftdi.so.1 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc22.i686 requires libascend.so.1 [ga] ga-openmpi-5.3b-9.fc21.i686 requires libmpi_usempi.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-pyt
Nonresponsive maintainers: Takanori Matsuura
According to Policy for nonresponsive package maintainers. Takanori Matsuura did not respond on https://bugzilla.redhat.com/show_bug.cgi?id=1105916, contact email is silent too. Moreover, his last build on koji was in late 2012. As for both above mentioned, I want to take ownership on CVector and NearTree packages that needed for rasmol package I maintain. krege -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Nonresponsive maintainers: Takanori Matsuura
Hello, On Thu, Aug 28, 2014 at 1:39 PM, Dmitrij S. Kryzhevich wrote: > According to Policy for nonresponsive package maintainers. > > Takanori Matsuura did not respond on > https://bugzilla.redhat.com/show_bug.cgi?id=1105916, contact email is silent > too. > Moreover, his last build on koji was in late 2012. I believe he's still active on twitter if you want to/can contact him this way: https://twitter.com/tmatsuu François -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fakesystemd package breaking builds
On Thu, 28.08.14 08:40, Lukáš Nykrýn (lnyk...@redhat.com) wrote: Heya, > I think that there was a problem in communication. We are *not* going to > create systemd-container in fedora. That was just for rhel, because at > least I wanted some quick and dirty solution. Our current plan in fedora > is patch systemd to run in docker and split the hwdb, that's all. Ah thanks! That makes a lot of sense, and is what we discussed in Prague! Did the things change their name since Prague, though? I thought systemd-container was called "minimal" back then? And fakesystemd was entirely news to me under this name... Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Re: Nonresponsive maintainers: Takanori Matsuura
Ahhh... Japan. I haven't twitter, but it could be fixed in no time. Thanks anyway. I'l try. > Hello, > > On Thu, Aug 28, 2014 at 1:39 PM, Dmitrij S. Kryzhevich wrote: > > According to Policy for nonresponsive package maintainers. > > > > Takanori Matsuura did not respond on > > https://bugzilla.redhat.com/show_bug.cgi?id=1105916, contact email is > > silent too. > > Moreover, his last build on koji was in late 2012. > > I believe he's still active on twitter if you want to/can contact him this > way: > https://twitter.com/tmatsuu > > François -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
DNF 0.6.1 Released
Hi, DNF 0.6.1 is out. For more info of this version see: http://dnf.baseurl.org/2014/08/28/dnf-0-6-1-released/ Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: PkgDB, pending ACL requests
On Thu, Jul 24, 2014 at 11:46:02AM +0200, Pierre-Yves Chibon wrote: > On Wed, Jul 23, 2014 at 04:25:54PM +0200, Pierre-Yves Chibon wrote: > > On Thu, Jul 17, 2014 at 03:28:56PM +0200, Pierre-Yves Chibon wrote: > > > On Wed, Jul 09, 2014 at 10:05:25AM +0200, Pierre-Yves Chibon wrote: > > > > Good Morning everyone! > > > > > > > > In the version 1.13 of pkgdb2 a new API endpoint has been added that > > > > just > > > > provide the list of pending ACL requests: > > > > https://admin.fedoraproject.org/pkgdb/api/pendingacls > > > > > > > > I just wanted to share with you the first line of its output: > > > > > > > > # Number of requests pending: 5492 > > > > > > Today we are at: > > > > > ># Number of requests pending: 5410 > > > > > > So there is some improvements :) > > > > Today's number is: > > > > # Number of requests pending: 5151 > > > > We got 341 requests that have been either accepted, rejected of withdrawn > > over > > the last two weeks, but we still have some pending :) > > > > So don't forget to visit: > > https://admin.fedoraproject.org/pkgdb/acl/pending/ > > I found out yesterday that this list contains pending ACL requests for package > that have been retired. > So I fix this in 1.18 (just deployed), so we're down to: > > # Number of requests pending: 4744 Going down: # Number of requests pending: 4323 I'm sure we can still do better :) Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Circular dependencies in RPM
On Tue, Aug 26, 2014 at 10:55:56AM +, Petr Pisar wrote: > On 2014-08-25, Miroslav Suchý wrote: > > Or we can wait for F21, which will have weak dependencies in RPM. And > > I anticipate that weak dependencies will break a lot of circles. > > > Does Fedora have guidelines what should and what should not be a weak > dependency? > > My experience with Perl packages is that "declaring dependency because it's > recommended but the package works without it" is quite seldom. The > majority of build cycles are either build-time dependencies for tests or > hard run-time dependencies (the Perl module exits with an exception > without the dependency in some code paths.) > > In my opinion, it would be much more appreciated if Fedora had > a mechanism to express "I want support for PDF" on the installed system > and then package manager would use this boolean to install or skip > affected dependencies. (This is the case of "some code paths" from > previous paragraph.) Would virtual provides give us that? Packages A, B and C have "Provides: pdf_reader" and Package B has "Requires: pdf_reader". The issue would to determine which provider to install, and do you ask the user to install it first or maybe install a "recommended" package? -- Darryl L. Pierce http://mcpierce.blogspot.com/ Famous last words: "I wonder what happens if we do it this way?" pgpNuzODE86ZE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fakesystemd package breaking builds
On Thu, 28.08.14 07:24, Daniel J Walsh (dwa...@redhat.com) wrote: > >>> But regarding kmod/devicemapper, can we please get some stats about how > >>> big this individually are, and how much is saved by this? kmod at least > >>> is 150K or so only. Is there really any value in doing this weird stuff > >>> for a fricking 150K?! Fedora has no bigger fishes to fry? > >> I'll prepare stats for you tomorrow. > >>> The systemd-container or fakesystemd stuff sounds awfully adhoc. Can we > >>> please always discuss this first, and see if we can find a different > >>> solution? We don't need three different "solutions", if one works > >>> too... > >> We've talked about this on Flock - it's not only about disk space > >> but also about security reasons (CC'ing Dan Walsh). My goal was not > > Dan, can you elaborate what the rationale for this is? > > It is not about Security escalation is is about the need to update a > container image if a CVE happens on any of the packages installed. > Basically we want to keep the turn on images as small as possible. If > systemd, kmod, udev ... have a CVE and they are not used within an > image, then we would still need to update the image because it > containers "Vulnerable" code, or potentially vulnerable code. Is kmod/systemd really that bad with CVEs? I mean, if there was a large number of them, maybe that's something to think about, but I see 2 in 2012, and 5 in 2013, and 0 in 2014... and those are not really the biggest issues in the world either, and certainly not in any way relevant if you just leave the files lying around > Fakesystemd was developed for RHEL/Centos images to help minimize the > CVE footprint. This was discussed on on this fpc request. > https://fedorahosted.org/fpc/ticket/425. I actually did not want > fakesystemd to go into Fedora for exactly the fear of it screwing up > builds. I like the idea of systemd-container, or some other minimal > systemd environment which understands and works well within container, > and am trying to get pull requests into docker to allow systemd to > work well. > > https://github.com/docker/docker/pull/7685 > https://github.com/docker/docker/pull/7685 > > If we got a good version of systemd-container, (Or systemd) which did > not suck in other requirements an stopped other random rpm sucking in > stuff not needed in container, I would be all for dropping fakesystemd. I don't think there's any value in having a second version of systemd for containers. We repeatedly made clear that we care about containers upstream, and want that systemd works fine in containers out of the box. I want a unified OS that works in any way executed. But by inventing thigns like "systemd-container" or "fakesystemd" you just create two more crappy options that don't fully work. Really, we should emphasize the value of our platform and its APIs, what you are doing there is just splitting up things into a crude variety of half-working, half-supported hacks. Let's just see what changes we can make upstream and in the systemd rpm in fedora, don't start doing things like fakesystemd/systemd-container without first trying to do these things properly, upstream and in the default RPM. For example, let's split out the hwdb stuff in Fedora, and maybe some other things, and then you can drop that from the container images, but let's not wildly invent new hacks, without checking if there are better ways... Thank you very much, Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fakesystemd package breaking builds
On 28 August 2014 12:10, Lennart Poettering wrote: > On Thu, 28.08.14 07:24, Daniel J Walsh (dwa...@redhat.com) wrote: > > > >>> But regarding kmod/devicemapper, can we please get some stats about > how > > >>> big this individually are, and how much is saved by this? kmod at > least > > >>> is 150K or so only. Is there really any value in doing this weird > stuff > > >>> for a fricking 150K?! Fedora has no bigger fishes to fry? > > >> I'll prepare stats for you tomorrow. > > >>> The systemd-container or fakesystemd stuff sounds awfully adhoc. Can > we > > >>> please always discuss this first, and see if we can find a different > > >>> solution? We don't need three different "solutions", if one works > > >>> too... > > >> We've talked about this on Flock - it's not only about disk space > > >> but also about security reasons (CC'ing Dan Walsh). My goal was not > > > Dan, can you elaborate what the rationale for this is? > > > > It is not about Security escalation is is about the need to update a > > container image if a CVE happens on any of the packages installed. > > Basically we want to keep the turn on images as small as possible. If > > systemd, kmod, udev ... have a CVE and they are not used within an > > image, then we would still need to update the image because it > > containers "Vulnerable" code, or potentially vulnerable code. > > Is kmod/systemd really that bad with CVEs? I mean, if there was a large > number of them, maybe that's something to think about, but I see 2 in > 2012, and 5 in 2013, and 0 in 2014... and those are not really the > biggest issues in the world either, and certainly not in any way > relevant if you just leave the files lying around > > Past performance does not indicate future pains. It doesn't matter if an application even have had 0 in the past.. the idea of having to respin every image because of a piece of software which isn't needed but is included in everything will cause the bristles go up for any large organization that must pass audits. (or a company that hosts for companies that must pass audits). It doesn't matter that it can't be used to break out of the image etc.. it is more about potential work and what can cause that potential work. [This is non-rational but is how things work and after twenty years of telling people that putting antivirus on a linux desktop doesn't solve a problem... it isn't the sort of problem which goes away with a rational argument.] -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fakesystemd package breaking builds
On 08/28/2014 02:10 PM, Lennart Poettering wrote: > On Thu, 28.08.14 07:24, Daniel J Walsh (dwa...@redhat.com) wrote: > > But regarding kmod/devicemapper, can we please get some stats about how > big this individually are, and how much is saved by this? kmod at least > is 150K or so only. Is there really any value in doing this weird stuff > for a fricking 150K?! Fedora has no bigger fishes to fry? I'll prepare stats for you tomorrow. > The systemd-container or fakesystemd stuff sounds awfully adhoc. Can we > please always discuss this first, and see if we can find a different > solution? We don't need three different "solutions", if one works > too... We've talked about this on Flock - it's not only about disk space but also about security reasons (CC'ing Dan Walsh). My goal was not >>> Dan, can you elaborate what the rationale for this is? >> It is not about Security escalation is is about the need to update a >> container image if a CVE happens on any of the packages installed. >> Basically we want to keep the turn on images as small as possible. If >> systemd, kmod, udev ... have a CVE and they are not used within an >> image, then we would still need to update the image because it >> containers "Vulnerable" code, or potentially vulnerable code. > Is kmod/systemd really that bad with CVEs? I mean, if there was a large > number of them, maybe that's something to think about, but I see 2 in > 2012, and 5 in 2013, and 0 in 2014... and those are not really the > biggest issues in the world either, and certainly not in any way > relevant if you just leave the files lying around Well systemd just showed up in RHEL7, but as I said, the goal was to limit the exposure. We were seeing systemd, kmod, udev and a few other packages being sucked into a container that only needed httpd. Every package we add is a possibility of a CVE and forcing us to rebuild. >> Fakesystemd was developed for RHEL/Centos images to help minimize the >> CVE footprint. This was discussed on on this fpc request. >> https://fedorahosted.org/fpc/ticket/425. I actually did not want >> fakesystemd to go into Fedora for exactly the fear of it screwing up >> builds. I like the idea of systemd-container, or some other minimal >> systemd environment which understands and works well within container, >> and am trying to get pull requests into docker to allow systemd to >> work well. >> >> https://github.com/docker/docker/pull/7685 >> https://github.com/docker/docker/pull/7685 >> >> If we got a good version of systemd-container, (Or systemd) which did >> not suck in other requirements an stopped other random rpm sucking in >> stuff not needed in container, I would be all for dropping fakesystemd. > I don't think there's any value in having a second version of systemd > for containers. We repeatedly made clear that we care about containers > upstream, and want that systemd works fine in containers out of the > box. I want a unified OS that works in any way executed. But by > inventing thigns like "systemd-container" or "fakesystemd" you just > create two more crappy options that don't fully work. > > Really, we should emphasize the value of our platform and its APIs, what > you are doing there is just splitting up things into a crude variety of > half-working, half-supported hacks. > > Let's just see what changes we can make upstream and in the systemd rpm > in fedora, don't start doing things like fakesystemd/systemd-container > without first trying to do these things properly, upstream and in the > default RPM. > > For example, let's split out the hwdb stuff in Fedora, and maybe some > other things, and then you can drop that from the container images, but > let's not wildly invent new hacks, without checking if there are better > ways... > > Thank you very much, > > Lennart > I agree, as I said, I did not want any of these to show up in Fedora. My understanding of systemd-container (minimum) was just a rebuild of systemd code to not require these additional packages. If we can end up with regular systemd running within a container and not requiring kmod/udev and others that would be great. Similarly not starting any services/getty's/SySV Services. I agree that systemd should just work and I hope that happens going forward with Fedora, so we can get it working in RHEL/Centos. In the end a multi-service container with httpd and mariadb should end up with systemd, journald, httpd* and mariadb* processes. Nothing else and as close to minimal packages as httpd and mariadb require to run. Lennart, I think we are in agreement, and you understand our needs. My end goal is to make systemd the default multi-process container manager and never ship cruft like supervisord. I would also like to -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: OCaml 4.02.0+rc1 rebuild (was: Re: Contacting the Ocaml maintainers)
On Tue, Aug 26, 2014 at 3:08 PM, Richard W.M. Jones wrote: > Go for it if you have time. If not then I'll ask in a few days. Asked here: https://groups.google.com/forum/#!topic/fa.caml/C6_VauENVgo -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
