Nonresponsive maintainer: Takanori Matsuura
Takanori Matsuura (fas: tmatssu) cant be reached for a long time. There are no reply on email, in bugreport [1], there are no koji builds [2], even more, from the previous message, Jiro Matsuzawa tell he contact him personaly (a week ago) nut there were no actions. At all mentioned above, I request orphaning Takanori Matsuura's packages: NearTree [3] and CVector [4]. Dmitrij. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1105916 [2] http://koji.fedoraproject.org/koji/userinfo?userID=1247 [3] https://admin.fedoraproject.org/pkgdb/package/NearTree/ [4] https://admin.fedoraproject.org/pkgdb/package/CVector/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Samba as AD DC
Hi, Is (Samba) Fedora 20 still not capable of being Active Directory Domain Controller? I mean is that page current: http://fedoraproject.org/wiki/Features/Samba4#Current_status ? Thanks in advance! -- -- Sergio Belkin http://www.sergiobelkin.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-readahead
On Sat, Sep 06, 2014 at 10:18:20PM +0100, Richard W.M. Jones wrote: > > Whenever my laptop boots, the hard disk is pegged at 100% and the > machine is unusable for another 2 minutes because of > "systemd-readahead", a misguided attempt to optimize the boot process. > Did we agree to this when we adopted systemd as an init replacement? It was part of original feature: https://fedoraproject.org/wiki/Features/systemd Nb. readhead was removed from upstream systemd recently. Fedora can either follow upstream and drop it, or patch back in. And you can disable it on your system any time. > I don't remember init including all this other stuff. "systemd suite" is collection of utilities and APIs for building Linux systemd. It contains init among other things. Changing init was most discussed thing, but let's not pretend systemd == init only. -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| -- 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: Future changes in the new package and new branch processes
On 09/06/2014 03:09 PM, Pierre-Yves Chibon wrote: On Sat, Sep 06, 2014 at 07:52:52AM +0200, Ralf Corsepius wrote: On 09/05/2014 05:08 PM, Pierre-Yves Chibon wrote: * cvsadmin approves the creation of the new branch in pkgdb => branch creation broadcasted on fedmsg * git adjusted automatically What does this sentence mean? Create an empty branch or even to populate it from some other branch? The script creating the git branches has a mapping of which branch to create a new branch from [1]. So new epel7 branches will be created from the f19 branch. I wonder if we should rather create an empty branch and let the packager merge the branch of his/her interest back into this new branch. Thoughts? I think the only safe way is to create an empty branch and not to populate it, because there are many constraints to be considered before a package can be added to an older branch. E.g. a package may have a chain of dependencies, which can't be fullfilled because something else is missing on this older release and can't be upgraded to a compatible version. 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: systemd-readahead
On 09/06/2014 02:18 PM, Richard W.M. Jones wrote: Whenever my laptop boots, the hard disk is pegged at 100% and the machine is unusable for another 2 minutes because of "systemd-readahead", a misguided attempt to optimize the boot process. Did we agree to this when we adopted systemd as an init replacement? I don't remember init including all this other stuff. Then has been a readahead service in Red Hat distros for as long as I can remember. It seems to have a beneficial effect to me, but I've never tried benchmarking it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
HI On Sat, Sep 6, 2014 at 5:30 PM, Richard W.M. Jones wrote: > On Fri, Sep 05, 2014 at 09:35:10AM +0200, Tomasz Torcz wrote: > > /tmp has nothing to do with systemd > > The tmp-on-tmp misfeature is to do with systemd. > How? systemd works fine without it. Many distributions have switched to systemd without having tmp-on-tmps. You could file a FESCo ticket asking for it to be reverted if you have feel strongly about it (and I know you do) Rahul -- 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: New Group Calls For Boycotting Systemd
Hi On Sat, Sep 6, 2014 at 5:36 PM, Richard W.M. Jones wrote: > We need to decide if just because you manage to get an important core > package into Fedora 4 years ago, that means you can forever more push > any old stuff you want into Fedora, without going back and consulting > with the community and FESCo. > I am puzzled. Upstream doesn't need to consult FESCo for developing new features. However it does need to consult FESCo for Fedora integration and it seems that systemd has. Can you point out any counter examples? Rahul -- 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: New Group Calls For Boycotting Systemd
On Sáb, 2014-09-06 at 22:36 +0100, Richard W.M. Jones wrote: > On Thu, Sep 04, 2014 at 10:31:45AM -0500, Bruno Wolff III wrote: > > On Thu, Sep 04, 2014 at 16:11:37 +0100, > > Sérgio Basto wrote: > > >Hi, > > >[1] > > >since Fedora have some responsibility, unfortunately I think the group > > >have some valid reasons , systemd should be the replacement of > > >sysvinit , a built in DHCP !? why ? and others integration like crontab > > >should be modular, for someone else could use his own crontab . > > >OTOH , the support of systemd is not good, we got bug opened and they > > >are ignored as nothing happens, as for example bug > > >https://bugzilla.redhat.com/show_bug.cgi?id=1088619 > > > > Boycotting systemd seems like a waste of resources. The various > > legacy init systems have significant problems and staying with them > > forever isn't going to happen. If there is a large set of people > > that don't like the direction systemd is going, they should either > > be constructively participating in the systemd development process > > or trying to develop another alternative that fixes the problems > > with legcay init systems while moving in a direction they do want, > > if they want to accomplish something. I don't expect anything useful > > to come out of a boycott. > > The boycottsystemd website is stupid. and completely outdated , gentoo seems that already have systemd and uclibc-systemd also . Although few arguments, seems to me, valid . > However there is a wider problem here. The "systemd of Fedora 14/15" > is not the systemd of today. I agree 100% > We need to decide if just because you manage to get an important core > package into Fedora 4 years ago, that means you can forever more push > any old stuff you want into Fedora, without going back and consulting > with the community and FESCo. "On Qui, 2014-09-04 at 22:12 +0200, Ralf Corsepius wrote: Therefore I'd find it useful for systemd take a break and period of consolidation to sort out the bugs and impact of systemd on Fedora. " yeah this and Chris Adams wrote almost synthesized what I think. what is the systemd goals ? plans ? roadmap ? seems that systemd want to be a operating system. The other problem that folks see when systemd is widely spread on Linux, that is not easy to export to other unix flavors, because the dependencies on kernel and udev which I must agree is not nice, not just for them, but also for us. I understand and agree with logind, localed etc, the sysconfig in systemd and all what is about init scripts, but some other features are more difficult to understand, we must think on Linux to be in embedded systems to super-computer systems ... -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
On Thu, Sep 04, 2014 at 10:31:45AM -0500, Bruno Wolff III wrote: > On Thu, Sep 04, 2014 at 16:11:37 +0100, > Sérgio Basto wrote: > >Hi, > >[1] > >since Fedora have some responsibility, unfortunately I think the group > >have some valid reasons , systemd should be the replacement of > >sysvinit , a built in DHCP !? why ? and others integration like crontab > >should be modular, for someone else could use his own crontab . > >OTOH , the support of systemd is not good, we got bug opened and they > >are ignored as nothing happens, as for example bug > >https://bugzilla.redhat.com/show_bug.cgi?id=1088619 > > Boycotting systemd seems like a waste of resources. The various > legacy init systems have significant problems and staying with them > forever isn't going to happen. If there is a large set of people > that don't like the direction systemd is going, they should either > be constructively participating in the systemd development process > or trying to develop another alternative that fixes the problems > with legcay init systems while moving in a direction they do want, > if they want to accomplish something. I don't expect anything useful > to come out of a boycott. The boycottsystemd website is stupid. However there is a wider problem here. The "systemd of Fedora 14/15" is not the systemd of today. We need to decide if just because you manage to get an important core package into Fedora 4 years ago, that means you can forever more push any old stuff you want into Fedora, without going back and consulting with the community and FESCo. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
The systemd sysvinit replacement talked about in Fedora 14/15 was not the init system + other bogus features that is talked about today. 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 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
On Fri, Sep 05, 2014 at 09:35:10AM +0200, Tomasz Torcz wrote: > /tmp has nothing to do with systemd The tmp-on-tmp misfeature is to do with systemd. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-readahead
Am 06.09.2014 um 23:18 schrieb Richard W.M. Jones: > Whenever my laptop boots, the hard disk is pegged at 100% and the > machine is unusable for another 2 minutes because of > "systemd-readahead", a misguided attempt to optimize the boot process. > Did we agree to this when we adopted systemd as an init replacement? > I don't remember init including all this other stuff for most machines it improves performance it repleaces the seperated "readahead" service just because it happens between boot / login example: power on machine, get a coffee, login on virtual machines it is conditionally disabled as default ___ if you don't want that or have very slow disks: systemctl mask systemd-readahead-collect.service systemctl mask systemd-readahead-replay.service systemctl mask systemd-readahead-done.timer signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
systemd-readahead
Whenever my laptop boots, the hard disk is pegged at 100% and the machine is unusable for another 2 minutes because of "systemd-readahead", a misguided attempt to optimize the boot process. Did we agree to this when we adopted systemd as an init replacement? I don't remember init including all this other stuff. 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 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Old virt-v2v may be half-retired
I tried to retire the old virt-v2v package: https://admin.fedoraproject.org/pkgdb/package/virt-v2v However I likely only "half-retired" it because although I'm a package administrator, I'm not the owner, or something like that. In any case I'm coordinating with the package owner and we will have it retired properly by next week. The background here is that virt-v2v and virt-p2v have been rewritten upstream over the past 6 months. The new version is integrated into the libguestfs project. In Fedora virt-v2v will be built as a subpackage of libguestfs >= 1.27.39. All of the above applies to Fedora >= 21 only, not to any earlier versions, nor to EPEL. 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 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: blivet-gui announcement
On Sat, 2014-09-06 at 12:47 -0400, Simo Sorce wrote: > > I can believe it'd be hard work, but I think you overstate the case by a > > long way when you say it'd be impossible. It may be finicky work, but it > > seems unlikely that it'd be easier to write an entirely new partitioning > > app with all of blivet's capabilities from the ground up (with a good > > privilege model) than it would be to take advantage of all that existing > > code for doing the very difficult and complex work of partitioning, and > > retrofit a decent privilege model onto it. > > well given blivet is a library, shouldn't it be simple enough to put it > behind a dbus interface and have the GUI and actual operation be > separated by dbus and authorized via mechanisms like polkit or similar ? > > That should pretty much solve the privilege separation between gui and > core code. yeah, that'd be a first step, but presumably the 'ideal' model would distinguish between privileged and non-privileged library operations - mostly, I'd assume, examining current status won't need privs, but making changes will. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: blivet-gui announcement
On Sep 5, 2014 5:05 AM, "Vratislav Podzimek" wrote: > > Good news, everyone! We (me and CC'd Vojtech Trefny) would like to > introduce you the next generation tool for storage management -- the > **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python > library (originally Anaconda's storage management and configuration > tool) inspired by GParted and other storage management tools. Why not > use GParted you ask? The reason we came up with blivet-gui is that > none of the existing storage management tools supports all storage > technologies supported in modern Linux distributions. Anaconda does > support them all so it's only logical to take Anaconda's storage > backend, combine it with a nice, intuitive and in general > user-friendly frontend and build a standalone application for storage > management. > > The GUI of blivet-gui is heavily based on GParted's UI to minimize the > surprise which is very important in such a critical task as storage > management is. If you know how to work with GParted, you'll almost > instantly know how to work with blivet-gui. All requested changes are > just enqueued first and then processed/committed to disk by the > "Apply" button just like in GParted. However, with blivet-gui those > actions may be something like the following sequence: > > create 10GB partition sda1, create a LUKS device on top of it and use > the LUKS device as a PV for a VG called ``dataVG`` with a single LV > ``data`` occupying half of the VG space and with XFS on top of the LV, > > not only partitioning and file system operations like GParted does. > > Having troubles writing partitioning part of a kickstart file for > automated installation? Run blivet-gui with the ``--kickstart`` option > and export the partitioning portion of a kickstart file instead of > committing changes to disk. > > On top of the features described above, the blivet-gui is embedable so > any application using any toolkit with the XEmbed protocol support > (Gtk, Qt,...) may use blivet-gui as a part of its GUI. > > The application only started its history few months ago, is under > heavy development now and will get new features in the next months > (RAID, BTRFS), but even now it is a very nice and useful tool. > > Suggestions, feature requests, bug reports and of course PATCHES ARE > WELCOME! It is quite a simple Gtk application written in Python which > makes it an easy target for everybody who misses something in the > other storage management tools. Don't like Gtk? Text mode would be > really, really useful too! Don't feel like adding new features and > diving deep in blivet to implement them? The code always needs > refactorization and cleanup! > > I think everybody can submit patches for blivet-gui and I'm really > looking forward to see the hundreds of patches from all those people > that hate every storage management GUIs and tools that have every > existed. Let's spend some time on pushing the Linux storage management > further instead of just complaining! > > .. [1] http://blog.vojtechtrefny.cz/blivet-gui > > P.S. Do you know about any other mailing lists or individuals that may > be interested in this announcement? Feel free to forward the message and > spread the word! > This looks excellent, thank you. I look forward to the BTRFS integration, let me know if you have questions on that front. Super excited to see something non-gnome specific. Thanks, Josef -- 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: Dist-git for Copr
Hi On Sat, Sep 6, 2014 at 12:48 PM, drago01 wrote: > > Well the FPCA seem to talk about this if someone that didn't sign it > sent you a patch all he/she has to do is to provide it under an > "acceptable license". > Yes but we artificially make it seem like FPCA is a requirement even when it isn't https://lists.fedoraproject.org/pipermail/board-discuss/2011-June/010792.html Rahul -- 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: Dist-git for Copr
On Sat, Sep 6, 2014 at 5:33 PM, Rahul Sundaram wrote: > Hi > > > On Sat, Sep 6, 2014 at 11:22 AM, drago01 wrote: >> >> Huh? What makes one legally not eligible to contribute? Just not >> signing the fpca? How is that different from someone that submits a >> patch via bugzilla / mail / whatever? >> I don't think people check whether those patch submitters have signed >> the fpca and neither do I think they should. > > > This is a problem that I have with the FPCA and I have highlighted it the > advisory board list before and no action was taken. Fedora project members > are enforcing it in places where it would be perfectly acceptable to take a > patch under an open source license without enforcing the FPCA requirement > unnecessarily. There is no legal basis for that. Well the FPCA seem to talk about this if someone that didn't sign it sent you a patch all he/she has to do is to provide it under an "acceptable license". -- 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: blivet-gui announcement
On Fri, 2014-09-05 at 23:47 -0700, Adam Williamson wrote: > On Fri, 2014-09-05 at 18:03 +0200, Lennart Poettering wrote: > > On Fri, 05.09.14 11:52, Matthias Clasen (mcla...@redhat.com) wrote: > > > > > On Fri, 2014-09-05 at 15:55 +0200, Vratislav Podzimek wrote: > > > > On Fri, 2014-09-05 at 09:04 -0400, Bastien Nocera wrote: > > > > > > > > > > - Original Message - > > > > > > Good news, everyone! We (me and CC'd Vojtech Trefny) would like to > > > > > > introduce you the next generation tool for storage management -- the > > > > > > **blivet-gui** tool [1]_. It is a GUI tool based on the blivet > > > > > > python > > > > > > library (originally Anaconda's storage management and configuration > > > > > > tool) inspired by GParted and other storage management tools. Why > > > > > > not > > > > > > use GParted you ask? > > > > > > > > > > Actually my question is "why not gnome-disk-utility?" :) > > > > Because it doesn't work well with LVM, RAID, BTRFS and a combination of > > > > them. > > > > > > Leaving LVM out was an explicit decision, because of all the system > > > integration problems with LVM. It works fine with RAID and btrfs as far > > > as I know. Do you have any concrete complaints about the RAID or btrfs > > > support in gnome-disk-utility ? > > > > Also, note that gnome-disk-utility actually properly separates out the > > unpriviliged UI from the priviliged backend in udisks. > > > > In this day-and-age we should not write new programs anymore that > > require the entire UI stack to run as root. We should really get away > > from doing something like that. In the blivet-ui docs "su" is the > > recommended way to invoke the program, and that's really wrong for a > > graphical one. > > > > gnome-disk-utility got that right. the new blivet ui did not. And this > > is not something you can add as an afterthought, you actually need to > > do your homework and split things up into privileged and > > non-priviliged parts from the beginning. > > > > The blivet-ui thing in this regard is certainly not an improvement over > > g-d-u, it's a step back. > > Well...I agree that in perfect theoretical engineering land, it'd be > nice if blivet-gui had a better privilege model. I think you're being > way too unnecessarily harsh, though, and missing a rather major point. > > blivet-gui is not 100% new code. The new bit is just the relatively thin > GUI wrapper. The really hard code - the bits that do the partitioning - > has existed for 15+ years: it's anaconda's partitioning code (lately > split out into python-blivet). And that code has *always* assumed it'll > run as root, because it's part of an installer that always does. > > If you want to use the blivet code as the base for a standalone GUI > installer and add a better privilege model, that was always going to be > a retrofitting job - even if you did it before doing this initial 0.1.x > release of blivet-gui, you're still retrofitting. It's really not a > significant difference. > > I can believe it'd be hard work, but I think you overstate the case by a > long way when you say it'd be impossible. It may be finicky work, but it > seems unlikely that it'd be easier to write an entirely new partitioning > app with all of blivet's capabilities from the ground up (with a good > privilege model) than it would be to take advantage of all that existing > code for doing the very difficult and complex work of partitioning, and > retrofit a decent privilege model onto it. well given blivet is a library, shouldn't it be simple enough to put it behind a dbus interface and have the GUI and actual operation be separated by dbus and authorized via mechanisms like polkit or similar ? That should pretty much solve the privilege separation between gui and core code. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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: Dist-git for Copr
Hi On Sat, Sep 6, 2014 at 11:22 AM, drago01 wrote: > Huh? What makes one legally not eligible to contribute? Just not > signing the fpca? How is that different from someone that submits a > patch via bugzilla / mail / whatever? > I don't think people check whether those patch submitters have signed > the fpca and neither do I think they should. > This is a problem that I have with the FPCA and I have highlighted it the advisory board list before and no action was taken. Fedora project members are enforcing it in places where it would be perfectly acceptable to take a patch under an open source license without enforcing the FPCA requirement unnecessarily. There is no legal basis for that. Rahul -- 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: Dist-git for Copr
On Sat, Sep 6, 2014 at 5:07 PM, Dennis Gilmore wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, 04 Sep 2014 17:34:57 +0200 > Miroslav Suchý wrote: > >> Hi, >> we (the Copr team) would like to allow uploading of source RPM to >> Copr. It seems that best way is to utilize dist-git [1]. Then Copr >> will fetch sources and spec file from dist-git and build SRC.RPM the >> same as Koji does now. And hopefuly you will be able to use fedpkg to >> interact with Copr. >> >> I see two options available: Copr will have its own dist-git instance >> or we will share dist-git together with Fedora. There are pros and >> cons for both and I would like to summarize it. >> >> 1) Copr will have its own dist-git instance >> Pros: >> * no possible conflicts with Fedora >> * installation of dist-git is tracken in ansible playbook in >> infra.git, so it should be straightforward (although Pavol Babincak - >> current maintainer of dist-git - claimed he had hard times to >> reproduce the installation) Cons: >> * require additional machine (Fedora currently use 8GB RAM + 2 GB >> swap and 1 TB of disk) >> * and additional maintance (although Pavol Babincak claims that >> there are no problems with running instance, he barely need to touch >> it) > Pavol is one of the maintainers he is not the only one. > > >> 2) Copr will share dist-git with Fedora >> Pros: >> * no maintenance of new machine >> * a lot of source are same and shared in look-aside cache (less >> data stored) >> * technically easily possible. E.g. for package 'rpm' in Copr >> project msuchy/foo we can create branch 'msuchy/foo' of dist-git >> 'rpm'. There are separate ACLs for each branch, so owner of >> 'msuchy/foo' branch could not affect branch 'f20' and vice versa. >> Cons: >> * dist-git use MD5 for checksum [2] therefore it can be practicaly >> possible to find collision with existing tar.gz and upload new >> version and Koji will use that file instead. > I do not see this as a huge issue > >> * Koji currently build from given SHA of commit of dist git and >> does not check if it is in correct branch. Therefore it can be >> theoreticaly possible to submit to Koji build from Copr branch. Afaik >> you still have to have ACL for that given branch in Fedora, so only >> Fedora package maintainer can do that and he obviously have no reason >> for that, but still... technicaly possible. > as long as the commit is in git anyone with a koji cert (i.e. > potentially anyone who has signed the fpca) can submit a build. until > we have ways to make sure builds are from an appropriate branch in koji > I will strongly oppose sharing of dist-git > > >> * Legal differences - users of Copr does not have to belong to >> CLA_DONE group. Can it make some problems? I do not know. > yes it can, I do not think we should accept contributions from people > who have not agreed to the fpca. I do not want to get into a situation > where a fedora maintainer pulled commits from a copr repo into Fedora > and we are being asked to remove them because they legally could not > contribute. Huh? What makes one legally not eligible to contribute? Just not signing the fpca? How is that different from someone that submits a patch via bugzilla / mail / whatever? I don't think people check whether those patch submitters have signed the fpca and neither do I think they should. -- 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: Dist-git for Copr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 04 Sep 2014 17:34:57 +0200 Miroslav Suchý wrote: > Hi, > we (the Copr team) would like to allow uploading of source RPM to > Copr. It seems that best way is to utilize dist-git [1]. Then Copr > will fetch sources and spec file from dist-git and build SRC.RPM the > same as Koji does now. And hopefuly you will be able to use fedpkg to > interact with Copr. > > I see two options available: Copr will have its own dist-git instance > or we will share dist-git together with Fedora. There are pros and > cons for both and I would like to summarize it. > > 1) Copr will have its own dist-git instance > Pros: > * no possible conflicts with Fedora > * installation of dist-git is tracken in ansible playbook in > infra.git, so it should be straightforward (although Pavol Babincak - > current maintainer of dist-git - claimed he had hard times to > reproduce the installation) Cons: > * require additional machine (Fedora currently use 8GB RAM + 2 GB > swap and 1 TB of disk) > * and additional maintance (although Pavol Babincak claims that > there are no problems with running instance, he barely need to touch > it) Pavol is one of the maintainers he is not the only one. > 2) Copr will share dist-git with Fedora > Pros: > * no maintenance of new machine > * a lot of source are same and shared in look-aside cache (less > data stored) > * technically easily possible. E.g. for package 'rpm' in Copr > project msuchy/foo we can create branch 'msuchy/foo' of dist-git > 'rpm'. There are separate ACLs for each branch, so owner of > 'msuchy/foo' branch could not affect branch 'f20' and vice versa. > Cons: > * dist-git use MD5 for checksum [2] therefore it can be practicaly > possible to find collision with existing tar.gz and upload new > version and Koji will use that file instead. I do not see this as a huge issue > * Koji currently build from given SHA of commit of dist git and > does not check if it is in correct branch. Therefore it can be > theoreticaly possible to submit to Koji build from Copr branch. Afaik > you still have to have ACL for that given branch in Fedora, so only > Fedora package maintainer can do that and he obviously have no reason > for that, but still... technicaly possible. as long as the commit is in git anyone with a koji cert (i.e. potentially anyone who has signed the fpca) can submit a build. until we have ways to make sure builds are from an appropriate branch in koji I will strongly oppose sharing of dist-git > * Legal differences - users of Copr does not have to belong to > CLA_DONE group. Can it make some problems? I do not know. yes it can, I do not think we should accept contributions from people who have not agreed to the fpca. I do not want to get into a situation where a fedora maintainer pulled commits from a copr repo into Fedora and we are being asked to remove them because they legally could not contribute. > Pavol suggested us to have our own instance. But I know there are a > lot of people from infra, legal and other team, who can add something > insightful before we start working on this. > > [1] Although I heard one voice saying we should move from home brew > code to more standardized git-annex [2] move to SHA is work in > progress https://fedorahosted.org/rel-eng/ticket/5846 > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUCyM2AAoJEH7ltONmPFDRHbIP/jxmr3wwWGwqxju1O6XncTac DAPzSSrkUVHvDjdNVt8PCRkVPISGYheKKQubbMems6yC5WpdtncShuv8ww3Yx/+9 WE2ikaAkawi5klPgGkTY1xTBpRV+tmSLXdVd+8A7XS+G9NLpAvhqj+9/AF3F0GHJ mTFZR6jVDE+elNN1DO+fQm88yi21zUie40YPPv8E5yE629PJM4GSwIrA+oqvIBjX YJmXXvOvji9jtGV2hcB8+JVQLKi+n6zJZatRf22CPK9hYCue/AQNzzpMBcYF/nOi WIdncqU10HPFGpJi4RqEfM0mq2Fl0DSP2zfdaD6zzheJCkeDydzUwmc8fD3M8Zcr r0VmZg9l0zl/xwR5dVDlE4agwy1ijoY1PMBMBSIqNe4bUeFX6PxtcWyQk8K5QmQi r1+vrTePo5M5+d7Mw9A4y2hsyuju14VB25JqgGoEpmE4gM0KXTXwaHbISDlEt8g7 AbM8VgiuHERrSvdEMHwLViaqN/07bVMNvsO0IvMS87UDzWWRkuIRuIe4QnJhppE7 aAMOzF5JqweSz6QyVdjTIhIAdjXimakJVCFiTyy5a/8BXMub60UFekXiYmG1/hdO sSlNUnb54e0RtQqPW9/aQl2PxUyfpYy1tDGLF6K1k4TjIijSB6FIduaS2onnI8zm DtJtenHmyz/WxhG1PDUa =GXK3 -END 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: Future changes in the new package and new branch processes
On Sat, Sep 06, 2014 at 07:52:52AM +0200, Ralf Corsepius wrote: > On 09/05/2014 05:08 PM, Pierre-Yves Chibon wrote: > > >* packager requests new branch in pkgdb (2 clicks) > > => requests added to the scm admin queue > >* cvsadmin checks the request/package (check if package exists in the RHEL > >for > > EPEL branch request - check if the user is a packager done in pkgdb > > itself) > I guess, EPEL is just an example for a "new branch" to create? Indeed, it's just an example. > We also have cases were packages only exists in newer Fedoras (eg. rawhide > only), until someone comes along and asks for branches to be created in > older Fedoras. We would have to clear it with releng, but I wonder what are the mandatory checks to perform when creating a new *fedora* branch for a package that has already been reviewed. If the only check is: is the person a packager?, then I guess we may be able to automatically create the fedora branch in pkgdb (which would then propagate the change to git). > >* cvsadmin approves the creation of the new branch in pkgdb > > => branch creation broadcasted on fedmsg > >* git adjusted automatically > What does this sentence mean? Create an empty branch or even to populate it > from some other branch? The script creating the git branches has a mapping of which branch to create a new branch from [1]. So new epel7 branches will be created from the f19 branch. I wonder if we should rather create an empty branch and let the packager merge the branch of his/her interest back into this new branch. Thoughts? Pierre [1] http://infrastructure.fedoraproject.org/infra/ansible/roles/distgit/templates/pkgdb_sync_git_branches.py see BRANCHES_FROM -- 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: Future changes in the new package and new branch processes
On Fri, Sep 05, 2014 at 08:12:49PM +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Sep 05, 2014 at 05:08:39PM +0200, Pierre-Yves Chibon wrote: > > Dear all, > > > > In the last months, Till and I together with infrastructure and > > release-engineering have been thinking and working on how we could improve > > the > > current workflow for new package and new branch. > > > > To give you an idea, this is the current workflow: > > > > Current new-package procedure: > > == > > > > * packager opens a review-request on bugzilla > > * reviewer sets the fedora-review flag to ? > Is this necessary? Normally having status=ASSIGNED is enough to know > that the review is handling the review. One of the issues with current > procedure is that this step can be forgotten, and then some automatic > steps don't happen when the flag to +. (One that I noticed it that the > email with subject 'fedora-review granted' is not sent.) > Since you're simplifying the procedure, this manual step could be > pruned too. That's a good question, but I don't know how many tools we have that relies on this flag and I suspect there are some. That's a question to bring to releng I guess. 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: Future changes in the new package and new branch processes
On Fri, Sep 05, 2014 at 06:35:45PM +0200, Haïkel wrote: > 2014-09-05 17:08 GMT+02:00 Pierre-Yves Chibon : > > Dear all, > > > > In the last months, Till and I together with infrastructure and > > release-engineering have been thinking and working on how we could improve > > the > > current workflow for new package and new branch. > > > > To give you an idea, this is the current workflow: > > > > Current new-package procedure: > > == > > > > * packager opens a review-request on bugzilla > > * reviewer sets the fedora-review flag to ? > > * reviewer does the review > > * reviewer sets the fedora-review flag to + > > * packager creates the scm-request and set fedora-cvs flag to ? > > * cvsadmin checks the review (check reviewer is a packager, check if > > reviewee > > required a sponsor or not, check if there was a review) > > * cvsadmin processes the scm-request: > > - Create git repo > > - Create package in pkgdb > > * cvsadmin sets fedora-cvs flag to + > > > > We thought that a number of these steps could be automated. For example, > > creating the git repos themselve could be automated using information from > > pkgdb. > > > > Our idea has been to port part of this procedure to pkgdb itself. > > > > This is our proposal: > > > > overall, kudos for this proposal, it looks better than the current workflow. > > One question, when do we close the review ticket ? > Currently, it is supposed to be handled by the reviewee after the > first build but it is often forgotten. Off course, it's the > responsability of the reviewer to check this but it's an impediment. > Astute people use bodhi to automatically close the ticket when it's > build on a branched release, but it's not possible on rawhide. > > From what I understand, pkgdb2 would be able to link a package to its > review, so it should be possible to automatically close the review > ticket, am I right ? We can go several ways there: a) let it the way it is now - Closed manualy - Closed via bodhi - Closed after a while when somone goes through his/her list of tickets and see that some can be closed b) let pkgdb close the ticket (once the package is created) c) let pkgdb close the ticket when the only branch requested is rawhide (once the package is created) Obviously, a) requires the less work, b) is easy but c) kind of make more sense as in theory it should be bodhi that closes the ticket (cf a)). > > New new-branch procedure: > > = > > > > * packager requests new branch in pkgdb (2 clicks) > > => requests added to the scm admin queue > > * cvsadmin checks the request/package (check if package exists in the RHEL > > for > > EPEL branch request - check if the user is a packager done in pkgdb > > itself) > > * cvsadmin approves the creation of the new branch in pkgdb > > => branch creation broadcasted on fedmsg > > * git adjusted automatically > > > > *nods* > Silly question, some of those cvsadmins checks could be automated too, > at least, providing hints to the scm admins. > Something like a script listening to fedmsg, doing these checks and > then sending the results that could be consumed by pkgdb2 (maybe > displaying them as flash messages ?) Since the checks will be performed by cvsadmins, manually, I think it make more sense to do them when the admin runs the script rather than automatically based on a fedmsg. Integrated back from fedmsg to pkgdb this type of information might not be easiest thing for no clear advantage, I think. Thanks for the feedbacks and ideas, 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
F-21 Branched report: 20140906 changes
Compose started at Sat Sep 6 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
rawhide report: 20140906 changes
Broken deps for i386 -- [APLpy] APLpy-0.9.8-5.fc21.noarch requires pywcs [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 [blender] 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blender-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blender-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 [bustle] bustle-0.4.7-2.fc22.i686 requires libHSdbus-0.10.7-ghc7.6.3.so [compat-gcc-34] compat-gcc-34-c++-3.4.6-29.fc19.i686 requires libstdc++ < 0:4.9.0 [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) [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dnssec-nodes] dnssec-nodes-2.0-5.fc22.i686 requires libval-threads.so.14 dnssec-nodes-2.0-5.fc22.i686 requires libsres.so.14 [dogtag-pki] dogtag-pki-10.2.0-1.fc22.noarch requires pki-ra >= 0:10.2.0 [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 [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 [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 [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-python2-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.i686 requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [gfal2] gfal2-plugin-srm-2.6.8-3.fc22.i686 requires libpugixml.so.1.0 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.i686 requires libmetacity-private.so.0 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.10.0-4.fc21.i686 requires libupower-glib.so.2 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [lcg-util] lcg-util-1.16.0-3.fc21.i686 requires libgfal.so.1 lcg-util-libs-1.16.0-3.fc21.i686 requires libgfal.so.1 lcg-util-python-1.16.0-3.fc21.i686 requires libgfal.so.1 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.i686 requires
Re: GNOME 3.13.91 megaupdate
On 09/01/2014 12:40 PM, Kalev Lember wrote: > I'm running point on the 3.13.91 builds and will submit it as a single > megaupdate in Bodhi later this week. The megaupdate is out now and available in updates-testing. I'd appreciate testing and feedback at https://admin.fedoraproject.org/updates/FEDORA-2014-10210 Thanks, Kalev -- 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: blivet-gui announcement
On Friday 05 September 2014 23:57:46 Adam Williamson wrote: > I like GNOME Disks, it's a great handy toolbox for doing > simple manipulation of drives, but I'm not sure it quite fits the same > mental box as blivet-gui would, for me. So, to extend the theoretical POV the way to go may have been: * Make the backend (udisks or equivalent) use python-blivet for a complete partitioning stack. * Let GNOME Disks expose only a "naive-user-friendly" subset of the functionality. * Let a full "blivet-ui" expose the full functionality. (obviously it's easier for me to do the talk than do the walk ;-) On another related front, can anyone relate this to similar technologies: * SystemStorageManager (https://fedoraproject.org/wiki/Features/SystemStorageManager) * openlmi-storage (https://git.fedorahosted.org/git/openlmi-storage.git) * The last one is even implemented in python. Just to make clear -- I think multiple competing solutions in the same domain are totally OK, especially when it's not clear which technologies will get traction. So even though running UI's as root is really bad, thanks for the blivet-ui people for the effort to expose an important storage stack. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron But it does move! -- Galileo Galilei -- 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: blivet-gui announcement
On Sat, Sep 6, 2014 at 8:57 AM, Adam Williamson wrote: > On Fri, 2014-09-05 at 11:52 -0400, Matthias Clasen wrote: >> On Fri, 2014-09-05 at 15:55 +0200, Vratislav Podzimek wrote: >> > On Fri, 2014-09-05 at 09:04 -0400, Bastien Nocera wrote: >> > > >> > > - Original Message - >> > > > Good news, everyone! We (me and CC'd Vojtech Trefny) would like to >> > > > introduce you the next generation tool for storage management -- the >> > > > **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python >> > > > library (originally Anaconda's storage management and configuration >> > > > tool) inspired by GParted and other storage management tools. Why not >> > > > use GParted you ask? >> > > >> > > Actually my question is "why not gnome-disk-utility?" :) >> > Because it doesn't work well with LVM, RAID, BTRFS and a combination of >> > them. >> >> Leaving LVM out was an explicit decision, because of all the system >> integration problems with LVM. It works fine with RAID > > No, it doesn't: > > https://git.gnome.org/browse/gnome-disk-utility/commit/?id=820e2d3d325aef3574e207a5df73e7480ed41dda > > the RAID support was entirely removed with that commit. > >> and btrfs as far >> as I know. Do you have any concrete complaints about the RAID or btrfs >> support in gnome-disk-utility ? > > So far as btrfs goes - well, I wouldn't say complaints, but it's not at > all in the same capability league as blivet. > > I just booted a current F21 nightly (so, current gnome-disks code) and > the extent of its ability to create new btrfs filesystems seems to be > 'you can format a partition, pick "Custom" as the "Type", and set it to > btrfs'. > > That's fine so far as it goes, but it's a long way from really > 'supporting' btrfs. btrfs isn't a simple filesystem like FAT or NTFS or > ext or xfs. It's more of an all-singing, all-dancing combined > filesystem/volume management/redundancy/kitchen sink arrangement. blivet > actually understands all of this, it really *supports* btrfs: you can > create btrfs volumes that span multiple disks, configure a lot of their > attributes, and create and configure subvolumes within the volumes. > Unless I'm missing something, gnome-disks does none of that. > > Honestly I don't see that gnome-disks and blivet-gui would be entirely > playing in the same sandbox. It might be viable to think of them as > GNOME's 'Network' control panel applet vs. nm-connection-editor, or > something along those lines? But probably with even more of a > difference. I like GNOME Disks, it's a great handy toolbox for doing > simple manipulation of drives, but I'm not sure it quite fits the same > mental box as blivet-gui would, for me. Yeah I don't think its an issue to have multiple applications for the same purpose. We have more than one app for pretty much all other tasks. As for the privileged vs. unprivileged ... that should be fixed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
