Re: BIOS boot - an alternative approach
On 2022-04-18 18:25, Ian Pilcher wrote: ... Basically, I suggest that Fedora stop worrying about BIOS boot or other "weird" boot configurations. Instead, provide a truly manual installation path where all boot and storage configuration is the responsibility of the user. ... I am using Fedora in the way very close to your suggestion, except the installer part. Since I am producing bunch of os instances of all types regularly (for me and my users), many years ago, I replaced Anaconda/kickstarts with ansible inventory per site (pure-man CMDB) abusing the ansible groups inheritance as tool for quick instance description. On top of these inventory calculations I have few stupid playbooks: * efi/legacy-pxeboot, lio-iscsi lease: optional, needed when the machine being installed is physical and blank (no ssh) * disk-layout: gpt (sfdisk), mdraids, lvm groups/pools/volumes (direct commands, build in ansible modules are incomplete), mkfs/mkswap invocations. * base fedora-image: systemd-nspawn+dnf (package list as sum of the classes in which the instance belongs), systemd.mount/swap/netdev/network, locale, etc. * efi-boot/bios-boot (extlinux/pxelinux based in both cases): initial copy of the kernal/initramfs, extlinux --install, initial extlinux.conf - it is simple. Then with the live (ssh accessible) freshly baked image - the usual ansible setup (subsystems, users, user profiles), according the instance purpose. When the new instance is a "upgrade", merge and restore configuration overlay from previous system using fossil VCS at /. On kernel updates, stupid python script in /etc/kernel/install.d/ for keeping extlinux.conf in sync. Nowadays the extlinux.conf script is superfluous - extlinux config could be generated on the fly form systemd's /boot/loader/entries/ with a Lua script (syslinux have Lua module), but I don't have written it yet. So, not much drama, for the sites with a some techy guy around, there is no shortage of variants (for both legacies support and efficient setup methods). The really hard problem which Anaconda is supposed to solve, are the new, non-tech users - somewhere in the Internet, alone, guided by incomplete/wrong recipes, found on a random forum/blog by google :-). Kind regards, Alek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
On 2020-07-02 13:08, Peter Robinson wrote: I suppose "very good state" is a relative term, upstream hasn't seen a release since 2016 so is essentially "unmaintained", not sure it supports secure boot, probably has a bunch of CVEs (see point about maintenance). I think it only lives on in Fedora is because I think it's used for some (.iso?) install method, AFIACT it's eventually glued back together when it fails to build and is generally ignored. As "very good state" I meant that the subpackages contain everything needed, and the binaries work flawlessly for the above use cases. Before, in some cases I was forced to use binaries from the upstream tarball. I started to collect the sources (the upstream repo, various branches like [1]), Fedora patchset, the "dist-gits" from other distributions listed in Repology [2], bug trackers), and will try to give more informed answer to your questions once I manage to asemble something ala src-git with pair of branches (patches/applied) per distribution. Kind Regards, Alek [1] https://github.com/awalls-cx18/syslinux/commits/master [2] https://repology.org/project/syslinux/versions ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 2020-06-30 14:34, Jóhann B. Guðmundsson wrote: Share your thoughts and comments on how such move might affect you so feedback can be collected for the future on why such a change might be bad, how it might affect the distribution and scope of such change can be determined for potential system wide proposal. Just in case if someone is not aware: syslinux (pxe, ext) shipped with Fedora is in very good state - form about 2016 I am using the package for all my booting needs (grub2 is too complex for me): * PXE/Legacy,UEFI * Physical (partition) Legacy, ESP-UEFI * VM Legacy - for VMs (and USB sticks) usually it is not even needed to partition the VM disk, just extlinux the VM FS volume. I do not tried VM/UEFI so far. so (in my experience) any instance will have easy switchable UEFI/Non-UEFI boot option even if the other bootloaders discontinue legacy mode support. I do not know if syslinux/extlinux have support in Anaconda, since I am not using Anaconda for my imaging needs. Kind Regards, Alek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using ndb in RPM
On 2017-07-10 12:28, Jos Vos wrote: Hi, On Mon, Jul 10, 2017 at 09:14:07AM +0100, Richard W.M. Jones wrote: The web page has: Improvements and stabilization of "ndb" (New RPM DB Format database format) [...] The problem is that "NDB" is a custom homebrew database invented in the RPM codebase. I agree that because of licensing problems we need to move away from Berkeley DB, but why not switch to the obvious, bulletproof choice - Sqlite? Totally agree with Rich. If the problem with sqlite is the lack of SQL developers, I am highly motivated to work on all SQL queries needed for such backend, leveraging the whole bunch of fantastic features in recent sqlite. SQLite is is totally different piece of cake (RDBMS vs. key/value). If you say: create table col1(key blob primary key, value blob) without rowid;/ you physically get no more/no less simple key/value store (given 30 more lines of trivial code for implementing your favorite key/value lib operations). But you are right - sqlite is different piece of cake: sqlite has powerful query language. Sqlite based backend gives the future advantage that big chunk of the rpm code could be elegantly and declarative offloaded to the query engine (with efficiency benefits as bonus). Kind regards, Alek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: iproute package update policy
On 2016-03-14 21:42, Phil Sutter wrote: ... So I will stick to my former plan of not rebasing iproute in stable releases (unless there's good reason) but become open for feature requests if there is valid need for it, a backport is feasible and it doesn't interfere with core functionality. ACK? Or both (at the price of additional cycles) - in addition to rebase-on-release for the main collection, (might be even without the selective post-release feature back-porting part), a semi-official COPR [1] repo in sync with the current kernel, to be available (for instance) to the dedicated sysadmins, who support bigger Fedora environments, like these in some universities. I think that recently more and more maintainers of key packages in Fedora also start to follow this (Main-conservative + COPR-latest) delivery scheme in favor of their users/testers with special interests. Kind Regards, Alek [1] https://copr.fedorainfracloud.org/coprs/psutter/iproute/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat
Hi Chris, On 2015-09-22 04:26, Chris Murphy wrote: ... For the cloud image, extlinux actually works. The problem pops up with any image intended for baremetal whre UEFI Secure Boot support is needed, and right now GRUB2 does and extlinux doesn't, so any "atomic" image would need GRUB2. While you are on the topic again (*) :-), could you please explain the technical details of the above syslinux.efi/ldlinux.e64 limitation and the possible approaches to overcome it. Thanks, Alek (*) In the current thread "Re: RFC: switching from grubby to grub2-mkconfig" -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Current Rawhide problems you might want to know about
On 14.10.2015 00:13, Richard W.M. Jones wrote: On Tue, Oct 13, 2015 at 03:00:27PM -0600, Chris Murphy wrote: Maybe strace will show where it gets hung up? Tried it of course - strace doesn't work across the setuid boundary. Maybe I can attach a trace tool (which?) to sshd (how?) and find out where it is spending its time. This stuff should be easier ... Sysdig [1] logs all (or some if filter is specified) syscalls via kernel module (in binary format like tshark): sysdig -w /tmp/all.scap sysdig -r /tmp/all.scap Kind regards, Alek [1] http://www.sysdig.org/install/ -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On 24.01.2014 21:20, Daniel J Walsh wrote: No, we pretty much allow executable stack/memory from user processes now and block it for most daemons, except for those that need it. My understanding of this change is that the kernel was not doing complete checking, but most apps at this point do the right thing. We will turn it on in Rawhide and through the beta. If we see problems we will revert. It is now a one line change in SELinux newbie question: Where the daemons exception is actually defined. My practical interest is: What should be added to LuaJIT [1] to be able to run e.g. non-packaged web servers like [2]? Thanks, Alek [1] http://pkgs.fedoraproject.org/cgit/luajit.git/plain/luajit.spec [2] https://github.com/kernelsauce/turbo -- 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: RPMbuild mystery parameters "--with" and "--without"
On 20.01.2014 16:24, Björn Persson wrote: According to the Packaging Guidelines we're not supposed to use those parameters when building "the source RPM to be submitted", because they somehow get "serialized" into the source package. I don't understand this, because I don't submit any source packages. The source package gets built on a Koji server when I run "fedpkg build", and I don't know of a way to pass any options to that process. IMHO, an example of reasonable usage of this RPM facility in the current context is the samba.spec: http://pkgs.fedoraproject.org/cgit/samba.git/plain/samba.spec It defines --with testsuite, which is not supposed for real binary packages production. Instead, it builds the full Samba (with the AD bits enabled) and performs the whole testsuite on top of the test build. Kind regards, Alek P.S. Fedora .spec provided Samba AD works very well for me. If someone is interested to deploy Samba AD on Fedora 20, and is aware of MIT vs. Heimdal Kerberos caveats _or_ are used with deployment in isolation (dedicated instance, container) there are couple of COPR RPMs available: http://copr.fedoraproject.org/coprs/decalek/samba.dc/ -- 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: NetworkManager Bridges in Fedora
On 18.01.2014 03:34, Adam Williamson wrote: On Fri, 2014-01-17 at 08:57 -0500, Steve Dickson wrote: On 17/01/14 07:30, Harald Hoyer wrote: journalctl -b _SYSTEMD_UNIT=NetworkManager.service better use # journalctl -b -u NetworkManager "-u" has the advantage, that you can specify it multiple times with different units and get a combined output. Good go know... thanks! How long has that parameter been in systemd now, Harald? Is it safe to suggest it for all supported Fedoras (F19, F20, Rawhide) at least? Thanks! -u works since systemd versions shipped with F18. Woth F19: [root@hpos2 ~]# rpm -qf $(which journalctl) systemd-204-18.fc19.x86_64 [root@hpos2 ~]# journalctl -u /var/lib/libvirt/qemu/save --since '-1 month' -- Logs begin at Thu 2013-03-21 02:04:44 EET, end at Sat 2014-01-18 14:51:07 EET. -- Jan 08 10:51:39 hpos2.posnet.sofia-airport.bg systemd[1]: Unmounting libvirt vms save space... Jan 08 10:51:40 hpos2.posnet.sofia-airport.bg systemd[1]: Unmounted libvirt vms save space. -- Reboot -- Jan 08 11:09:14 hpos2.posnet.sofia-airport.bg systemd[1]: Mounting libvirt vms save space... Jan 08 11:09:14 hpos2.posnet.sofia-airport.bg systemd[1]: Mounted libvirt vms save space. Kind regards, Alek -- 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: Inter-WG coordination: Stable application runtimes - SCC: Fedora social
On 12.01.2014 22:34, Alek Paunov wrote: - sccd-web: WebUI exposing full functionality, alternatively Cockpit (OpenLMI WebUI) extension. ... - NTH: SCC local state inheritance between instances Fedora Social: Almost every developer or sysadmins like to demonstrate how clean and clever is his own design :-). Currently we do not have a service where Sandra, Joe and George [1] could: - show and share with the others their Fedora based setups - conveniently keep the setup for their own reuse in the future Once we have sccd-web and few NTHs, we will be nearly (at least as code) equipped to provide something like "github for Fedora setups" for publishing, referring in the e-mails and forking Fedora users work. [1] http://fedoraproject.org/wiki/Server/Personas -- 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: Inter-WG coordination: Stable application runtimes
On 12.01.2014 22:34, Alek Paunov wrote: [*] Crucial aspect of any sophisticated data management system is the data query and manipulation language. Unfortunately the choices are rather limited - Imperative approaches (recently resurrected by some NoSQL DBs) are weak and error prone; SQL and few more "text prose" languages have proven their incompatibility with the vast majority of the developers (these without years of specific experience around the data volumes processing). The predominant workaround seems to be ORMs, but ORMs and "sophisticated/fast" should not be mixed in same project :-). My personal preference leans towards rules approach (which e.g. is also adopted by at least one of the ERP innovation leaders - LogicBlox) and especially its variant of visual rules definition UIs, where the user describes dependencies (relations) between source and result trees of a operations using blocks and arrows, and then the compiler lowers the the whole transaction definition to executable (by the DB engine), procedure. IMHO, such kind of visual interface would be one of the possible adequate languages (Adequate to the DB specialization level of our target audience, including big share of the developers). My personal preferences for the lower level executable language and DB engine are LuaJIT procedures on top of SQlite4/LSM C API. -- 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: Inter-WG coordination: Stable application runtimes - SCC
On 12.01.2014 22:34, Alek Paunov wrote: So, finally on that road we have: ... - NTH: remote SCC DB for the instance, - NTH: SCC local state for multiple instances (e.g. deployment nodes or local containers) kept in the same SCC DB - NTH: SCC local state inheritance between instances Another closely related topic is the system snapshotting or in other words - system "flavors" variants/subvariants tree. Even before the btrfs magic, we have at hand wonderful snapshot mechanisms - LVM, qcow2+qemu-nbd-connect, ceph rbd, etc. Probably, LVM thinp currently is the best for the purpose of supporting tree of system variants. Once we apply FS snapshotting, combined with the SCC NTHs above, there are at least two appealing use-cases: - reusing one base e.g. F20 server container image for both the host and the incompatible containers (e.g. when one application requires nodejs 0.8 and another nodejs 0.10) - easy testbed for resolving the upgrade path for an existing, possibly non "pure Fedora" server with care about the deployed services. -- 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: Inter-WG coordination: Stable application runtimes
On 10.01.2014 21:12, Matthew Miller wrote: On Thu, Jan 09, 2014 at 07:58:44PM -0800, Adam Williamson wrote: So the question becomes, what is it appropriate for a distribution to do in this situation? My personal opinion is that what's appropriate for a distribution to do is also, happily, what's easiest for a distribution to do: punt on it. Entirely punt on the whole thing. And, this ultimately makes a better experience for users, because if Fedora's included tools are aware of the native packaging system, we can do things like system auditing, security alerts (if not updates), maybe even integration with selinux policy. Basically, we don't hammer all of the possible universe into the distribution model, and we don't include all of the packages of everything in the base Fedora distribution as RPMs, but we do include those ecosystems in the Fedora _Project_, including the tools and documentation to make them feel natural. Your expression " ... tools aware of the native packaging system" and the Andrew comment about the pip behaviors above in the thread, encouraged me to share my "big hammer of the DB plumber style" :-) opinion on the problem. TL;DR: What follows is SCC: An idea for optional DB and service which caches bits from YumDB, the local state (RPMDB and /etc) plus the "native" systems like NPM in the unified way for the purposes of planning, resolving and performing system state transitions. Initially I meant to say just few words to mark the possibility, but obviously my English and talent for easy for reading and well focused messages are both far from good, so the whole thing become too long and I am going to split some additional notes into self replays - Excuses! RPMDB and YumDB are two rich datasets present on every Fedora instance representing respectively the local state and distribution+ state of the package universe. '+' because +Fusion*, +COPRs, +LocalOrg, etc. Unfortunately they are somewhat hidden in the dark, because lack of interfaces - we even missing SVG or other explorer for the YumDB graph. The (let think of them as "virtual") Maven DB, PyPI DB, NPM DB, LuaRocks DB, etc, technically are subsets of YumDB (in sense richness of encoded logical relations between the DB nodes used in their schemes - e.g. PyPI DB, before the pip egg, do not knows which file from which module comes, nor have the concept of higher than package NV granularity of the requirement points - Provides and Requires in YumDB). Also, the depsolving of the "native" packaging systems is less sophisticated than both current yum and hawkey ones. These observation naturally lead to the idea of SCC: System Configuration Cache DB representing the merge of RPMDB, YumDB and e.g. local pip egs, PyPI DB (if e.g. additional python modules/versions are needed for the given deployment) where the depsolving could be shifted, somewhat in the same fashion as Data warehouse solutions are used in the enterprises for merging the significant datasets from various ERP systems into single DB for interactive time reporting and decision making. I am using the term SCC (vs. e.g. UPMC: Unified Package Metadata Cache) in attempt to cover a (paraphrased) Mirek question from the beginning of the thread - "OK, we have Fedora and PyPI integrated, at one point of the time for a given instance, the Fedora packaged module has been chosen. What happens if we upgrade Fedora along with am incompatible version this Python module for given installed service" - obviously we need to register in the SCC the dependencies of the installed machine roles with the same effect like Require clauses in the our packages, so the SCC machinery to validate (with negative result in this described case) the yum upgrade or to resolve the upgrade including installation of newest available compatible version from PyPI as an alternative provision during upgrade preparation. Further, I think that ideally SCC should parse/absorb as much as possible system object properties and relations from /etc (plus /lib and /var configuration areas) to allow sysadmins and devops to inject rules for effective use of these sets latter in the depsolving (and other DB functionality). That said, the integration with OpenLMI, or even implementing the whole thing under the OpenLMI umbrella, both seems natural. So, finally on that road we have: - choice for good enough DB engine for SCC, query language, compiler [*], etc. design decisions like sync protocol and plugable data sources. - Yum/RPM datasets: optional rpm, yum, hawkey hooks for syncing their DBs, alternatively just sync tools. - optional pip, npm, luarocks, etc. hooks for the same, alternatively just sync tools. - OpenLMI integration for absorbing system configuration, alternatively just Augeas import + transformation rules to sync the DB representation of the system objects. - sccd capable to: - depsolving (on top of cumulative - YumDB + native managers DBs, preferably providing interfaces to the
Re: enlightenment 0.18.1 etc...
On 05.01.2014 04:29, Bob Richmond wrote: I have no desire to become a package maintainer for Enlightenment, but I Even in this case, after the hard work already done by you, now it is possible binaries be delivered to the end users - Are you aware of the new COPR [1] service? After repo creating, your further rebuilds will be easy as: copr-cli build efl18 http://www.lorez.org/enlightenment/efl-1.8.3-1.fc20.src.rpm resulting in ready for use yum.repo in something like: http://copr.fedoraproject.org/coprs/bob/efl18/repo/fedora-20-x86_64/ (assuming copr-cli create efl18 setup step) Kind Regards, Alek [1] http://miroslav.suchy.cz/blog/archives/2013/12/29/how_to_build_in_copr/index.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: Introduction
Hi Tako, On 27.11.2013 15:01, Tako Schotanus wrote: Sorry for not responding to this before, but lots of other things to do and this packaging business obviously needs more than just an hour here or there of reading READMEs. NP, I just decided that you are in touch with the experienced packages who already offered to help/mentor the Ceylon stack packaging and they have guided you to some better workspace/workflow. I see you want to make things even more difficult for me by giving me *several* options to choose from, are you *trying* to torture me? ;) Is there somewhere I can read up on this way of managing packages? No. Perhaps the LuaJIT Fedora stack will be prepared/supported by the Lua community in that fashion, but it is just a plan at this time. And any particular reason why you would suggest making a new gitgub project for each of the Ceylon SPEC files instead of just putting them together? Wouldn't that just give us a bunch of 1-file projects otherwise? The intention is, the staged package repos to be in same shape as production repos: http://pkgs.fedoraproject.org/cgit/scala.git/tree/ http://pkgs.fedoraproject.org/cgit/coffee-script.git/tree/ i.e. one repo/SRPM per source based build (as Dridi emphasized in the previous mail, probably somewhere grouping tarballs (tar.gz) from more than one gh:ceylon/* repos) where latter build BuildRequires result RPMs from the previous or the Fedora NN platform resource (e.g. eclipse RPMs) containing same _fixed_ branches as the dist-git repos: http://pkgs.fedoraproject.org/cgit/coffee-script.git/refs/ To be persistent with the torture and complications :-), I would suggest you to additionally: - Create one top repo with the same branches (f21, f20, f19, etc): gh:fstack-ceylon: fstack-ceylon/ - submodule: ceylon ref: gh:fstack-ceylon/ceylon - submodule: ecliplse-ceylon-ide ref: gh:fstack-ceylon/ecliplse-ceylon-ide ceylon - ceylon.spec ecliplse-ceylon-ide - 0001-tweaks-for-eclipse-xxx-c1.patch - 0002-tweaks-for-yyy.patch ... - ecliplse-ceylon-ide.spec That way, you could deal with the whole stack, clonning/barnch-switching single fstack-ceylon repo (as you like in the question above), still keeping the (real) sub-repos dist-git ready. - When somewhere the need of patching arises (e.g. because of incompatibility between the base ceylon-something version for that dist branch e.g. f19 and the required platform components e.g. eclipse-xxx in f19) you can add "f19" branch directly in the respective gh:ceylon/something repo e.g. gh:ceylon/ceylon-ide-eclipse and then easily produce the required patches to the gh:fstack-ceylon/ecliplse-ceylon-ide in f19 branch, with git format-patch, see libguestfs: https://github.com/libguestfs/libguestfs/tree/fedora-20 http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/copy-patches.sh?h=f20 https://github.com/libguestfs/libguestfs/tree/rhel-7.0 ... Kind Regards, Alek P.S.: http://fedoraproject.org/wiki/Mailing_list_guidelines#If_You_Are_Replying_to_a_Message - Original Message ----- From: "Alek Paunov" To: "Development discussions related to Fedora" Cc: "Tako Schotanus" Sent: Friday, November 22, 2013 5:54:53 PM Subject: Re: Introduction On 22.11.2013 14:58, Tako Schotanus wrote: So I'm completely new to this packaging business, I managed to piece together a SPEC file that results in an actually working RPM for our project and even Koji seems to accept it, but there's so much information to absorb that I'm feeling a bit out of my depth. (Our project being a programming language we're dealing with some difficult issues with respect to versioning and such, for now I've copied Java's with alternatives and such which might or not be a good idea). So if there are some friendly people here that can guide me through my first real submission that would be great! I really don't know weather this idea is appropriate [*], but since Ceylon development is github based anyway and Ceylon is a fresh new development stack (according to Fedora.next terminology :-) ), what about new github account: fstack-ceylon (Ceylon related packages for Fedora) containing something like: gh:fstack-ceylon/ceylon/ceylon.spec gh:fstack-ceylon/ecliplse-ceylon-ide/ecliplse-ceylon-ide.spec ... etc formed in the same shape as the future dist-git repos (being drafts for them) for all the incoming Ceylon SRPMs. You could then clone/commit there your current .spec drafts and receive issues and pull requests containing packages improvements (e.g. with pointers to relevant guidelines parts) if it turns out that such style of community work on the specs seems efficient to the established packagers, who already offered help. I imagine few additional pros: - Ceylon stack packaging "story" collected under a github account can
Re: Introduction
On 22.11.2013 14:58, Tako Schotanus wrote: So I'm completely new to this packaging business, I managed to piece together a SPEC file that results in an actually working RPM for our project and even Koji seems to accept it, but there's so much information to absorb that I'm feeling a bit out of my depth. (Our project being a programming language we're dealing with some difficult issues with respect to versioning and such, for now I've copied Java's with alternatives and such which might or not be a good idea). So if there are some friendly people here that can guide me through my first real submission that would be great! I really don't know weather this idea is appropriate [*], but since Ceylon development is github based anyway and Ceylon is a fresh new development stack (according to Fedora.next terminology :-) ), what about new github account: fstack-ceylon (Ceylon related packages for Fedora) containing something like: gh:fstack-ceylon/ceylon/ceylon.spec gh:fstack-ceylon/ecliplse-ceylon-ide/ecliplse-ceylon-ide.spec ... etc formed in the same shape as the future dist-git repos (being drafts for them) for all the incoming Ceylon SRPMs. You could then clone/commit there your current .spec drafts and receive issues and pull requests containing packages improvements (e.g. with pointers to relevant guidelines parts) if it turns out that such style of community work on the specs seems efficient to the established packagers, who already offered help. I imagine few additional pros: - Ceylon stack packaging "story" collected under a github account can become a visible guide for the new stacks Fedora integration (especially for the potential contributors which are new to the tracking of the bugzilla.rh packaging bugs and the other Fedora communication channels). - the whole collection of the specs, when polished could be forked and tweaked for other RPM based distributions. Kind Regards, Alek [*] because 1) it seems that few voices are firmly against Fedora specific work on github and 2) this would lead to some bug-tracking fragmentation between github/bugzilla, but I hope the latter is more technical (synchronization/indexing) issue. -- 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: Using git for patch management in Fedora
On 20.11.2013 11:19, Richard W.M. Jones wrote: On Tue, Nov 19, 2013 at 03:36:54PM -0800, Toshio Kuratomi wrote: One note though, I think that in the past one of the discussion points we've foundered on is whether we want to be mirroring upstream's git repo or (approximately) upstream's releases. I think that's probably where we'd need to start discussion. From the point of view of patch management, I have a strong view here: We should be mirroring upstream's git, if they have one. The reason is that it makes it trivial to cherry pick upstream patches on top of the Fedora branch. So I'd arrange it by having a straight mirror of upstream, then have our own 'fNN-branch' branches which contain the upstream releases (ideally from upstream tags if they are using git sensibly) + our cherry picked patches. What you (and Daniel yesterday, and Karel, and ... likely everybody) clarifying is the natural scheme: fsource: XYZ: XYZ[ref1]: fNN-overlay XYZ[ref2]: fNM-overlay fsource[XYZ][fNN].acls <- dist-git[XYZ][fNN].acls dist-git[XYZ][fNN].patches <- XYZ[fNN-overlay] - XYZ[ref1] dist-git[XYZ][fNN].source <- XYZ[ref1].tarball Optionally: dist-git[XYZ][fNN].changelog <- ~.filter(~.patches) I have been thinking for intermediate steps with less resources allocation, but obviously there are consensus across the maintainers according the workable approach. Kind Regards, Alek -- 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: Using git for patch management in Fedora
On 19.11.2013 19:32, Daniel P. Berrange wrote: On Tue, Nov 19, 2013 at 07:27:20PM +0200, Alek Paunov wrote: What about intermediate step: optional "fNN-upstream" branch in addition to fNN, containing relevant upstream revision as git submodule (preferably referencing fedorahosted mirror, but initially also allowing "external" clones)? I think it would be better to keep the upstream repo separate for sake of size. People who just want to checkout the latest RPM branches don't want to have to pull down 100's of MB, potentially GB, worth of GIT repo, when current Fedora GIT repos are a mere few MB. Only maintainers actively updating patches need that burden. Git submodules are just references to external revision, not materialized inclusion of the referenced repo, aren't they? Someone should explicitly add --recursive or git submodule command to pull them. Kind Regards, Alek I just checked once again: git clone https://github.com/JulesAU/node-msgpack Working directory contains file .gitmodules with 3 lines: [submodule "deps/msgpack-full"] path = deps/msgpack-full url = https://github.com/msgpack/msgpack.git Site web interface shows: https://github.com/JulesAU/node-msgpack/tree/master/deps git submodule status: -d642487f9916dfe571531d0c6d0727b3ee449d36 deps/msgpack-full ls -al deps/msgpack-full: total 8 drwxrwsr-x 2 alek src 4096 Nov 19 20:06 . drwxrwsr-x 3 alek src 4096 Nov 19 20:06 .. However if: git clone --recursive https://github.com/JulesAU/node-msgpack node-msgpack-with-deps ls -al deps/msgpack-full: total 72 drwxrwsr-x 15 alek src 4096 Nov 19 20:14 . drwxrwsr-x 3 alek src 4096 Nov 19 20:13 .. drwxrwsr-x 4 alek src 4096 Nov 19 20:14 cpp drwxrwsr-x 2 alek src 4096 Nov 19 20:14 csharp ... -- 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: Using git for patch management in Fedora
On 19.11.2013 16:20, Daniel P. Berrange wrote: On Tue, Nov 19, 2013 at 01:29:06PM +, Richard W.M. Jones wrote: On Tue, Nov 19, 2013 at 01:39:50PM +0100, Karel Zak wrote: We have to learn fedpkg to do all the magic ;-) Something like add remote git tree with exploded tree: fedpkg exploded-tree add ssh://git.fedorahosted.org/git/foo.git This is all great, but the problem is that co-maintainers and provenpackagers need to be (automatically if possible) added to the fedorahosted tree. Otherwise there's a big extra step for them if they want to follow the package owner's preferred patching system. Ideally the GIT SCM request added to bugzilla when reviews are approved would have a "Upstream GIT URL" option and would setup a clone of this, and create branches for the fedora releases, and apply the same permissioning model from dist-git branches of the same names. What about intermediate step: optional "fNN-upstream" branch in addition to fNN, containing relevant upstream revision as git submodule (preferably referencing fedorahosted mirror, but initially also allowing "external" clones)? Kind Regards, Alek -- 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: unaccessability
On 17.11.2013 14:14, Nico Kadel-Garcia wrote: While this has been amusing, a lot of useful detail may be lost in the furor. There are some good philosophy questions about what GUI's should support for replacing command line tools (the gnome ... So step back, and let's think "how can we make this work for someone who hasn't seen it before and doesn't know how to hand-edit config files"? My answer would be: With an lightweight web consoles. Regular desktop users usually are scared by blank terminal window - They do not know what to type, also they are afraid that if they type something wrong and broke something then the severe sysadmin or the tech-y guy who was installed/supporting their system will be very angry :-) But they are curious to try new things, especially when the new thing could bring them something cool (like e.g. simple loop to convert their incoming media). The idea about the browser app, helping the users with command lines construction is not mine, I saw this in Cloud9 IDE (advanced browser based IDE, BTW, currently hosting user envs on OpenShift). They have command line at the bottom of IDE space, which exposes many of the IDE operations, offering code completion (visual equivalent of bash completion) for args filling + nice HTML (why not SVG) table results for (some of) the commands. If this exposure of the command line tools looks acceptable for more wide range of users, we could: * choose "standard" for backend/webapp communication (e.g. NullMQ/MsgPack with these and these messages) * choose "standard" args grammar, for describing valid command lines * choose "standard" results grammar, for parsing the utility output streams * make a reference metadata for tool or two, which in addition to the grammars, have references to the relevant man page sections for the subcommands and thier args. Given the e.g. above spec, the authors of current web based terminal emulators would be able to extend their projects, becoming funny and shiny command line composing (and why not simple snippets composing) tools and eventually package for Fedora. On the other side we can offer to upstreams (or maintainers, where willing) to add this pure metadata, which should be positive for them in two ways: * possibly their tool becomes easy to use and accessible for wider audience. * most of the projects, will benefit of any pure metadata definition of their in/out grammars and documentation cross-references, because they do not have any. I think, the Fedora as integrator of the half of the FLOSS software in the planet, with half of the Linuxes as downstreams is a good place for drafting such kind of standards. After the standards acceptance, the remaining part is easy - we could reuse the comps, tags, requires/provides in the packages, etc, to generate the Big Fat Fedora tools catalog (the pallete of the web console) - When the user wants to try a tool she clicks, we yum installing the thing and system is ready to be blown by this curious user :-) Kind Regards, Alek -- 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: rpm macro magic help
Hi Sandro,
On 07.11.2013 15:10, Sandro Mani wrote:
Uhm, how can one this be done? Shell variables are substituted after
macro expansion, so i.e.
function do_build {
arch=$1
qt_version=$2
%{mingw${arch}_qmake_${qt_version}}
}
would hardly work? Or are you suggesting passing the entire macros as
arguments? I.e.
function do_build {
qmake=$1
make=$2
${qmake}
${make} %{?_smp_mflags}}
[...]
do_build "%{mingw32_qmake_qt4}" "%{mingw32_make}"
For some time I am looking for a reason to test the Lua RPM feature:
http://rpm.org/wiki/PackagerDocs/RpmLua
Can you point me to the .spec in the question and a few more words which
is the desired result.
Kind Regards,
Alek
--
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: Fedora search
On 02.11.2013 02:32, Michael Cronenworth wrote: This will be my last mailing on this topic as I will not contribute or use this feature in Fedora, but this reply warranted clarification. On 11/01/2013 06:14 PM, Alek Paunov wrote: Another simple answer: CSE is a low quality search - no facets, no (real) content age restriction. The same is valid also for every other service/application which is solely based on generic web pages crawling. CSE is as full blown as a Google Appliance. More advanced than anything you can write in Perl/Python/Ruby in a month. Site restrictions, keyword restrictions, (real) age restrictions, autocomplete help, synonyms, image search, all of which are provided through a XML API.[1] Indeed. Don't get me wrong - I like CSE service for what it is good for. It seems that I had not been clear enough with my English - Sorry! Nobody is able to write a good, modern index in a month - lucene/solr, xapian, etc, are all evolved in long, long years. Our task is a proper deployment of one or combination of them, not inventing a new. Why e.g. solr instead of CSE or dpsearch (which is opensource, and also mentioned in the old tickets)? Granularity: With CSE/dpsearch the indexed content unit is a crawled and automatically processed Web document (I say Web document instead of HTML page, because CSE handles many types). Not single BZ comment. Not change comment in a spec file. Not Git commit. Or in the reverse direction: Email, not thread (because we do not yet have yet archive page displaying the whole thread). I.e. there are no concept of document and subdocuments (in which most of our content belongs). Attributes: You can not attach custom scalar/category attributes (the base of the faceted search) to the FTS indexed units. Please correct me if I am wrong about CSE with some of the above. Fedora has datasources (bugs, wikis, mails, packages, docs, etc,) not just sitemaps/pages, and they all talk about same things (common topic hierarchies, common tag hierarchies, common authors). They form highly interlinked virtual knowledge base. We should start index the sources in their native structure now, to be able to upgrade some happy day to full blown semantic search (when available), which is actually what we badly need. In our case, we are the owners of the content, we know how it is structured, we know where are the feeds with the pure content changes, we can explicitly feed the indexes with all named attributes of the content nodes and later use them. But you don't know how other people on the web find and link to Fedora pages to provide accurate page ranking. Personas: 1. Active Fedora contributor, 2. Fedora contributor, 3. Power Fedora user/sysadmin, 4. Fedora user, 5. Potential Fedora user, 6. IT journalist. IMHO, at least for 1-3 the results ordering by recursive link-rank valuation (Google page ranking) is more an issue than an advantage. For 4 (also important) the relevant sets are probably: the docs, part of wiki, ask.fp.o and might be users@. I don't know - not always stackoverflow 'relevance' top resuls on a set of keywords are the same as google with site:stackoverflow.com in the query ... For 5-6 Google page ranking is probably the best, but they will use Google instead of search.fp.o anyway (at least initially, latter their more concrete queries would be more like 3-4 ones). Kind Regards, Alek -- 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: Fedora search
On 31.10.2013 22:03, Dennis Gilmore wrote: Michael Cronenworth escribió: What about using a custom Google search engine? https://www.google.com/cse/ simple answer, its not open source Another simple answer: CSE is a low quality search - no facets, no (real) content age restriction. The same is valid also for every other service/application which is solely based on generic web pages crawling. In our case, we are the owners of the content, we know how it is structured, we know where are the feeds with the pure content changes, we can explicitly feed the indexes with all named attributes of the content nodes and later use them. IMHO, actually the first and more important step for us is these sources to be specified on a wiki page, and to be glued index feeding transports based on these source types. Kind Regards, Alek -- 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: Software management: Call for RFEs results!
On 04.10.2013 15:34, Jan Zelený wrote: If you have any other questions, comments or notes regarding the document, feel free to to use this list for the discussion. Where (list threads, wikis, sources) one should seek more details about the DB aspects of the plan, e.g.: * A1: Delta metadata in yum and dnf (format, replication mechanism) * B1-4: New format of rpmdb (db engine, schema, relation with the future yum/dnf db) Thanks, Alek -- 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: Software Management call for RFEs
On 28.05.2013 21:18, seth vidal wrote: On Tue, 28 May 2013 20:42:13 +0300 Alek Paunov wrote: So, it seems that yum already have the "filelists on demand" optimization implemented. Why you are asking for removing a feature, which do not make the things worse ... ? I'm not. But when you download the filelists - it is A LOT of data. It is of course :-). It is big and slow now, but it implements one more distinguishing and convenient Fedora feature ... and under careful schema and encoding, can be scaled down several times in both space and query time. Actually, every "positive" (install, update) yum operation implies access to the repos. Repos contain everything. If our software was perfectly optimized, not only filelists but all other parts of the database (including primary.files, which you have cited initially) should be lazily synced, right? I'd rather not have filedeps so it doesn't get pulled in for other things in depsolving. Sorry, I do not know how this amount of data will impact libsolv in the future. IMO, for yum (I mean in the sqlite based solution) it is a matter of optimizations. I have a few questions: * What is the reasoning behind the splitting of the database across many .sqlite files? many? it's 3 afaik. primary, filelists, other. how do you mean 'many? Multiplied by the number of the repos. That is what I am trying to understand - Why not just single .sqlite file for the whole yum database? * Why the sql schema is so denormalized (IMO, leads to both bandwidth and disk overspending without speed benefits)?. For example: Why provides and requires tables do not use the common domain table? B/c it was designed 8yrs ago and we were going for compressable space and making it as quick as possible to search? In the provides and requires example, we do not have any space/speed benefits achieved by the missing common domain (dependency + dependency_evr tables). In the current situation we have fat and slow text duplication and indexes instead of integer references to the domain subnodes (dependencies is the biggest domain in the primary). Yes, in bunch of cases a little denormalization is inevitable when we fight for speed, but IMO, this and few other space flaws are with negative impact on the speed too. * Why the incremental update mechanism (eg. applying xml diffs to the sqlite database) was not been considered from the very beginning? It wasn't necessary? There was a massively smaller number of pkgs to consider. Indeed. Also, 8 years ago the possibilities and the number of ideas to reuse were definitely different :-) Thank you, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 28.05.2013 18:51, seth vidal wrote: On Tue, 28 May 2013 08:51:03 +0200 Jan Zelený wrote: after a "yum clean metadata && yum update" on a slow line you have to wait a very long time and even the download of the presto-metadata often is larger and takes longer as the packages which are updated in reality hey on my 100 Mbit all is nice and fine but on a machine behind DSL with around 100 KB/Second it is way too slow and large and i refuse to imagine how this feels on a 56kbit modem I couldn't agree more. But as I have said, we need to find the most simple and unintrusive things that can be done to improve this. For instance: file lists take a considerable portion of the entire metadata size. But if we were to remove them, things like "yum install /usr/bin/vim" would not work any more. And you get similar scenario with almost all the metadata that we store - we store them for a reason and without them some things that people use will not work. Jan, the above is not correct. Files in *bin/* are in the primary metadata - not in the filelists. That was specifically designed to handle the 90% of file-deps which are *bin/* or /etc/*. It's not accidental. so if you nuked filelists entirely you'd only lose people who have filedeps on something outside of those wildcards above. I've spent HERCULEAN amounts of effort to whittle down the set of filedeps outside of that area. I filed hundreds of bugs on the subject in years passed. I simply got tired of tilting at that particular windmill when confronted with some particularly egregious cases (see libguestfs sometime). I just tested on a F18 box the following: yum erase -y datalog yum clean all yum install sqlite-datalog #3 non-existing package yum install -y /usr/bin/datalog In the above sequence, yum do not downloaded the filelists at all. yum erase -y datalog yum clean all yum install sqlite-datalog #3 non-existing package yum install -y /usr/share/lua/5.1/datalog.lua #4 In the second sequence, yum started the filelists downloading at #4. So, it seems that yum already have the "filelists on demand" optimization implemented. Why you are asking for removing a feature, which do not make the things worse ... ? If you have further questions about how the metadata works or was designed please feel free to ask me, directly. I believe I and Adrian Likins are the only current Red Hat Employees or Fedora Contributors who were present/involved in its original 'design'. Such as it was. I have a few questions: * What is the reasoning behind the splitting of the database across many .sqlite files? * Why the sql schema is so denormalized (IMO, leads to both bandwidth and disk overspending without speed benefits)?. For example: Why provides and requires tables do not use the common domain table? * Why the incremental update mechanism (eg. applying xml diffs to the sqlite database) was not been considered from the very beginning? Thanks! Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 28.05.2013 13:54, Jan Zelený wrote: On 28. 5. 2013 at 11:39:35, Alek Paunov wrote: On 28.05.2013 09:51, Jan Zelený wrote: I couldn't agree more. But as I have said, we need to find the most simple and unintrusive things that can be done to improve this. For instance: file lists take a considerable portion of the entire metadata size. But if we were to remove them, things like "yum install /usr/bin/vim" would not work any more. And you get similar scenario with almost all the metadata that we store - we store them for a reason and without them some things that people use will not work. Not so unintrusive, but would it be acceptable if we merge all .sqlite DBs from all repos in a single .sqlite with tree-like schema? Let say we achieve overall size reduction by factor of 4, at the price of more complicated but faster SQL queries. [I hope that such a change will also make the incremental by the XML sources easier] I am going to experiment this, if make sense ... Perhaps it's just that I don't fully understand your vision but I'm not sure that's a feasible solution. How exactly would you solve the fact that users have different repos enabled on their machines? Or did you mean merging them on the client side? That would not solve the issue of data download. Oh sorry. On the client side of course - these which are under the /var/cache/yum tree. My question was more targeted on the complains about 1) metadata local size, 2) speed and 3) capabilities of the local yum queries. [Furthermore you currently reformulating "Package Management" as "Software Lifecycle Management", so it would be normal for me to expect that the data backend will have to be enhanced accordingly. Or will libsolv stores be enough for all?] Regarding the metadata download speedup, I completely agree with Florian and others on the thread, that current bulk downloads should be replaced with XML only downloads and incremental update of the local DB as a first step and introducing *optional* metadata services (just XML git or something smarter) for the mirrors which are willing to upgrade. Thank you, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On 28.05.2013 09:51, Jan Zelený wrote: I couldn't agree more. But as I have said, we need to find the most simple and unintrusive things that can be done to improve this. For instance: file lists take a considerable portion of the entire metadata size. But if we were to remove them, things like "yum install /usr/bin/vim" would not work any more. And you get similar scenario with almost all the metadata that we store - we store them for a reason and without them some things that people use will not work. Not so unintrusive, but would it be acceptable if we merge all .sqlite DBs from all repos in a single .sqlite with tree-like schema? Let say we achieve overall size reduction by factor of 4, at the price of more complicated but faster SQL queries. [I hope that such a change will also make the incremental by the XML sources easier] I am going to experiment this, if make sense ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: lua 5.2
On 12.05.2013 00:10, Richard W.M. Jones wrote: FWIW the libguestfs transition to Lua 5.2 (done by the SuSE guys) wasn't completely straightforward. A handful of APIs have been removed or changed. These are the changes we had to make: https://github.com/libguestfs/libguestfs/commit/e987c038ead0a2398f13727ab1de518a216a1d50 https://github.com/libguestfs/libguestfs/commit/f07e89c5f90a1cef8e61428f30916d39ab35541b As many of Fedora developers know, LuaJIT [1] is a drop-in replacement of Lua 5.1. The author Mike Pall stays on his strong opinion to not upgrade the LuaJIT implementation of the language to 5.2 standard in the foreseeable future. His basic stand point is about keeping compatibility for the existing users. [1] http://luajit.org/performance_x86.html So, may be Fedora transition to 5.2 is the right moment for LuaJIT to be finally included in the collection (with an additional role as lua51-compat package - alternative provider of lua(abi) = 5.1 on all architectures except s390 and ppc64). Initially, back in the LuaJIT 2.0 beta times, there was one failed packaging attempt [2] who died due to disappeared candidate packager. [2] https://bugzilla.redhat.com/show_bug.cgi?id=718681 Meanwhile, after 2 years intensive beta period LuaJIT reached official 2.0 release (2012-11-12). Current version is 2.0.1-2 and 2.1 (with compiled string operations) is on the way - [3] (mirror). [3] http://repo.or.cz/git-browser/by-commit.html?r=luajit-2.0.git Personally, I not have learned all of the guidelines yet and do not feel ready to make proper reviews of other packages ( besides my recent hard times with bunch of stalled tasks :-( ), but there are another unofficial spec [4] and if Craig is willing to become leading maintainer I will be happy to apply as co-maintainer (not because package requires additional care, but as help with the bugs processing duties, if any). @Craig what you think? [4] https://github.com/craigbarnes/packages/blob/master/luajit.spec As a side note, LuaJIT extends Lua language with an unique FFI mechanism for direct leveraging the whole treasure of the collection provided C-APIs, coded as simple as [5] (compiled to native calls, without need of libffi or such), which makes it perfect for standalone system-scripting tool and/or Python companion [6]. [5] http://luajit.org/ext_ffi_tutorial.html#zlib [6] https://github.com/scoder/lupa Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dealing with static code analysis in Fedora
On 11.12.2012 23:52, David Malcolm wrote: We'd be able to run all of the code in Fedora through static analysis tools, and slurp the results into the database Dave, I really do not know what to say first :-). The subject is so important and there are so many aspects and application fields - IMHO, the topic is the most important one in the devel list lately (and is in _direct_ relation with the all other _hot_ topics - ABI stability, upgradeability, collections, reliable/automated migrations, packagers productivity, rawhide, etc.) I hope this thread will be long and fruitful discussion with the final effect to change Fedora to something that all motivated devs in the list expect it to become. Just few preliminary questions about your insights in the future: 1) What about dumping the GCC structs to the DB during the OS/Repos processing from the same beginning (means something more powerful than dxr.mozilla.org, and possibility to engage various static analysis people to the project, like Masaryk University team as Michal reported, without the locking to concrete compiler technology/encoding) 2) Clang world enrolled the (suspicious) term "Compilation database" as the safe sequence and arguments of the compiler invocations for a package build. What is your opinion for abstracting build systems to the DB in the same way in Fedora (based on the GCC plugin)? 3) As I said already, IMHO, this thread is the most practically important topic in Fedora. What about SIG/Team? I think base of 8-10 high experienced part-time contributors will be enough for your spec and 1)-like enhancements. Kind Regards, Alek P.S. Fedora infrastructure resources are mandatory for the final Fedora repos cooking, but I think that the community is able to provide less secure, but much more in volume resources for the analysis workers (Fedora can just supply small enslaving script for the dedicated VM) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub (v1) in f18?
Hi Rich, On 07.12.2012 18:54, Richard W.M. Jones wrote: Well this is a more general question about virtualization. I agree that it's sometimes more convenient to use an external kernel and initrd to boot a guest, and libvirt supports this mode (see the and in libvirt XML). But: We are using libvirt in the above fashion for a while - with a little help from salt recently (on every yum (kernel) update the host changes the dom definition for the appropriate guest via the python (libvirt) bindings) Our disks for the VMs are regular ext4 LVs (without partitions and bootloaders) Thank you for the great platform! Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Hi Simon, On 28.11.2012 14:43, Simon Lukasik wrote: I can't see how this is related to my latest post. And I can't see what leads you to think that cross-platform scanning is feasible today (standard-wise and performance-wise). Please check this very informative post from Steve (OVAL board member): http://www.mail-archive.com/devel@lists.fedoraproject.org/msg50625.html We (the camp arguing for "flexible" configurations) should identify clever proposal at least conforming the following: * Will be able to be "cold" (statically) assessed through current or future OVAL (first and most important use-case - VM images evaluation, second - augeas and alike on the live systems, third - custom auditing agents) * Will looks cool for the sysadmins (the config languages users) (I am in doubt that any traditional scripting language will bring high score on this criteria) * Will enable desired (for the non-trivial cases) flexibility Kind regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LuaJIT - an alternative for current Python C bindings
Hi Florian,
On 15.11.2012 13:18, Florian Weimer wrote:
On 11/15/2012 01:49 AM, Alek Paunov wrote:
So, to me it seems natural joining all above together to start thinking
for replacing the classic python C bindings with thin textual or
bytecode(*) LuaJIT/FFI shims in benefit of things with great set of
dependencies like Anaconda (thanks to lupa, Lua objects behaves like
Python ones in Python). The result will be order of magnitude easier for
maintenance (towards the APIs evolution) and faster code.
LuaJIT is currently not available for our secondary architectures, so
this would need fixing first. ("not available" meaning exactly that,
there is no fallback to a slow C interpreter mode or something like that.)
Oh, I completely forgot the secondary architectures (besides ARM).
Florian, you follow LuaJIT - what other architectures (except the
clearly missing s390) should be covered ?.
It's also not clear how significant the actual memory savings will be
because some of the Lua OO frameworks have quite a bit of overhead. And
the eventually arriving abrt plugin will bring some weight with it, too.
This is nothing against Lua or LuaJIT. I just don't think that
switching programming languages will magically reduce resource
consumption. This has to be an explicit design goal, or else it is not
likely to happen. I'm sure it's possible to write resource-conserving
Python code, too. It's just the baseline overhead from the run-time
system which is unavoidable, but that's fairly small for Python
(apparently less than 2 MB of unshared RSS per process).
Apparently, my pseudo-English is not enough for a normal communication :-(.
I am commenting on the possibility for deploying LuaJIT FFI as a partial
replacement (problematic + future) of the hand written or SWIG Python
bindings in the first place, not switching the system language from
Python to Lua. In a system tool/daemon written in Python:
* Python loads libluajit.so (import lupa; from lupa import LuaRuntime;
...)
* The C libraries (the targets of the binding) are described as LuaJIT
FFI style bindings in simplified C [my primary point for that is
correctness (avoiding the memory leaks and reference counting problems)
and lowering the burden of the APIs evolution maintenance, not lowering
the general memory footprint]
* The current OO style Python wrappers (the higher level part of the
classical C bindings) are implemented with the Lua metamethods over
plain C objects (without any Lua OO frameworks)
* Python calls the LuaJIT C lib object wrappers (as close as possible
to the Python APIs exposed by the current bindings on top of the Python
C API).
Kind Regards,
Alek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LuaJIT - an alternative for current Python C bindings
On 15.11.2012 04:51, M. Edward (Ed) Borasky wrote: How much Python code are you proposing "someone" ports to Lua? ;-) I am proposing mostly porting C code to Lua/FFI (the code of the problematic Python C bindings) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 15.11.2012 04:32, Kevin Kofler wrote: Unlike the others, it generates the native code at runtime (Just In Time), so there is a performance penalty (especially for nontrivial programs) for the (JIT) compilation which gcc and ocamlopt won't have. The quality of the generated code could also be a problem (for nonempty programs): Optimized compilation takes time! So there's a tradeoff between the time of the JIT compilation and the time of the actual execution, a very fast JIT is not necessarily optimal because it may be missing important optimizations of the compiled code. All above is correct, with the small nuance that all practically significant slowdowns are always result of repeatable code paths (loops, recursions, etc) but these lands to near optimal native code after the first few iterations with this concrete implementation (Mike Pall is well known with his in-depth theoretical background). In other words: Try nontrivial benchmarks before claiming victory. I am. Check GSL shell for example. Nobody claims any victories (especially against gcc). The point is, that this concrete JIT is probably the fastest existing one and brings bunch of advantages at the cost of negligible footprint (compared with v8 for example). Have you played with LuaJIT apps already ... or speaking from common sense POV ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 15.11.2012 02:19, Lennart Poettering wrote: For containers a yum group for usage with --installroot= is the only thing that matters. FWIW, For me Anaconda is overkill for the KVM guest images too. I am used to do that with small xquery script (easy for the libvirt domain definition) containing: yum (conf, root) install setup kernel acpid chrony acl attr audit rsyslog dhclient openssh-server openssh-clients rootfiles yum (yum dep-solves the above to 152 packages for F17, x86_64) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
LuaJIT - an alternative for current Python C bindings (was: Re: raising warning flag on firewalld-default feature)
On 12.11.2012 21:34, Steve Grubb wrote: But the problem I see is a lot of libraries are wrapped by swig, which leaks memory like a sieve. If swig didn't generate such leaky code, Python based daemons wouldn't be as scary. IMHO, Python is one of the best ways to express management logic. As have stated elsewhere in the thread, from the footprint perspective, python-libs can be decomposed to something including much smaller python-libs-core. The remaining problem is the quality of part of the C bindings. Otherwise, it is great advantage for Fedora that huge part of the system tools are already polished in Python (my own experience is that the C code in many tools/libs shipped with Fedora is of relative poor quality, as already Miloslav explained). David Malcolm already has some real results addressing the Python bindings issues trough static analysis based on his great gcc-python-plugin/libcpychecker work. In the future, this machinery can be used for bug free bindings generation too. Another option for addressing this is ... to just get rid of part of them in their current form. LuaJIT 2.0 is a reimplementation of Lua scripting language, which has build the reputation of one of the fastest compilers (comparable only with gcc) in the course of his 3 years! beta cycle (2.0 final release was announced early this week) The size of luajit.so (interpreter + trace compiler + C parser for the FFI definitions) is 452088 bytes (on x86_64, for comparison sqlite3.so, which is a python requirement is 677672) Unlike other FFI implementations LuaJIT FFI works compiling the functions calls/C structs access to native code. Another difference is that the foreign C definitions are presented in native C syntax: http://luajit.org/ext_ffi_tutorial.html#zlib On top of this kind of FFI, LuaJIT already have bunch of library bindings - as instance the kernel ABI wrapper: https://github.com/justincormack/ljsyscall For a long time already Fedora ships lunatic-python (loading and bridging the Lua interpreter as python module) More recent and feature complete bridge is: https://github.com/scoder/lupa from the author of lxml module. So, to me it seems natural joining all above together to start thinking for replacing the classic python C bindings with thin textual or bytecode(*) LuaJIT/FFI shims in benefit of things with great set of dependencies like Anaconda (thanks to lupa, Lua objects behaves like Python ones in Python). The result will be order of magnitude easier for maintenance (towards the APIs evolution) and faster code. Furthermore, we can get LuaJIT for free, because it is full API/ABI compatible with current Fedora (PUC Rio) Lua 5.1, which is pulled by RPM anyway - we can just replace Lua with LuaJIT as RPM provider for F20. Kind Regards, Alek (*) Unlike original Lua, LuaJIT bytecode is portable across architectures. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 13.11.2012 18:35, Richard W.M. Jones wrote: Hmmm: $ echo '' > true.ml $ ocamlopt.opt true.ml -o true $ time ./true real 0m0.002s user 0m0.000s sys0m0.001s time luajit -e "require'os'; os.exit(42)" real0m0.001s user0m0.000s sys 0m0.000s But, check here for a far more important feature: http://luajit.org/ext_ffi_tutorial.html#zlib all this in 452088 bytes (libluajit.so, x86_64): This seems about right to me: Both ocamlopt & gcc generate native x86-64 programs, but there's a small amount of overhead in the OCaml binary (initializing the minor heap of the GC). luajit too (it is one of the fastest compilers) I will try to formulate an approach for Fedora to benefit from this little miracle in additional note (SWIG bindings problems above in the thread). Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Hi Steve, On 12.11.2012 21:00, Steve Grubb wrote: I think its a bad idea to have too much flexibility for access control systems. They have to be verifiable. If you have to comply to PCI-DSS or the DISA STIG or any other standard, you have to be able to demonstrate you are in the approved config. No one can write a test that can tell if the rules really are sound. So, what will happen is one set will be chosen for better or worse, it will be SHA256 hashed. And no one can change anything in it without being out of compliance. The benefit of the name=value setup is that we can pick out the things that matter and skip everything else which truly gives flexibility when needing to demonstrate compliance. My question is: Whether be acceptable the required compliance analysis to be performed on rules written in simplified rule language like Datalog instead of imperative scripted evaluation in some future version of polkit ... ? (It seems to me that e.g. Datalog is good enough both as flexibility and static analysis (symbolic evaluation), furthermore IMO declarative rules are less error prone for sysadmins than scripting) Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum upgrade from F17 to F18
On 08.11.2012 15:10, Miroslav Suchý wrote: [1] https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum Nice start, Thank you! I like the scripting (ifs) or even better a rule based (make-like) approach. I will test your script on few instances. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 05.11.2012 15:57, Simo Sorce wrote: A possibly viable alternative for the ABIs freezing (which we can not ensure anyway) is the C/C++/etc tooling - If we arm upstreams, packagers and 3rd parties with powerful source tools (API migration/checking), just like Google does internally, unsing the Clang tooling, witch was developed exactly for this purpose. The GCC/OpenJDK tooling development is not something appropriate as effort for the manpower of almost any upstream, but IMHO should be seen as important goal for relatively big player like Fedora. Unfortunately it won't work, unless you are ready to also go and mark reliable and unreliable upstreams, which is ... difficult. The reason I say so is that I know for sure not all upstreams are willing to maintain ABI compatibility. There are various degrees but some go for absolute ABI compatibility at all costs (glibc) to "I'll break the ABI on purpose (or because I don't care) at every upgrade (won't try to name names). My point was about the second group (dependency providers with evolving ABIs) and more specifically about the affected packages (their users - dependency consumers). When the consumers are short on resources or just don't really care so much about the current Fedora consistency, the problem naturally lands at the responsibility of the respective Fedora maintainers. The whole dance would be sufficiently different if we provide the cooperative upstreams with powerful tools for aligning their projects with the current/prepared release "compound" ABI. IMO, this means Fedora VMs (not necessarily sponsored by the project, I am sure that the Cloud SIG has enough magic at hand to orchestrate community/upstreams provided instances) and preinstalled compiler plugins based tooling - easy to use instruments for checking and fixing their sources according the release environment state. The above applies also for the third parties (propriety software vendors and these with open source licenses but not so open style of development) - they probably will spent few dozens of hours to "lint", once we provide them with ready to use "login and type 'make'" environment. Of course, not any upstream would be willing to cooperate - in this case we will have to handle the issue with our own resources, but again the tooling can reduce the time spent by the packagers with an order of magnitude. Fedora is almost always the First, once we start doing this proactive "Upstreams alignment" technology and effort, maybe other Linux OS vendors would join too. Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 04.11.2012 19:25, Simo Sorce wrote: note that this is "also" our strength in some respect because it allows the system to evolve a lot more quickly, but it also means upgrades are Indeed. simply going to break stuff, and that's not so great for desktop environments and scare the hell off of 3rd party vendors. You may notice we do not have many 3rd party vendors, I think ABI instability is reason number, 1, 2 and 3 of why we can't have reliable third parties with a community built OS. I agree completely with all your points. A possibly viable alternative for the ABIs freezing (which we can not ensure anyway) is the C/C++/etc tooling - If we arm upstreams, packagers and 3rd parties with powerful source tools (API migration/checking), just like Google does internally, unsing the Clang tooling, witch was developed exactly for this purpose. The GCC/OpenJDK tooling development is not something appropriate as effort for the manpower of almost any upstream, but IMHO should be seen as important goal for relatively big player like Fedora. Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 03.11.2012 19:17, Alek Paunov wrote: Adam, I think that the current "rolling release" discussion as many other "high interest" general ones in the recent months are pointless without some form of explicit definition and statistics of the current (and desired) distinct Fedora user profiles. Just because I said "general ones" which might be somewhat misleading, several examples: * The importance of Secure Boot workaround (in the proposed form) * The amount of the negative impact of /tmp on ramfs feature * The importance of a "Software Center" existence etc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
On 03.11.2012 18:26, Adam Williamson wrote: On Sat, 2012-11-03 at 10:52 +0100, drago01 wrote: Eh? That's not what I said at all. What I said was that I think in a well-managed rolling release model, users would actually run into trouble only about as often as they already do anyway. I don't mean they'd only get updates every six months, I mean they'd only get updates which _broke stuff_ on average every six months. Or less. Adam, I think that the current "rolling release" discussion as many other "high interest" general ones in the recent months are pointless without some form of explicit definition and statistics of the current (and desired) distinct Fedora user profiles. You mostly talk about the uncle Bob's profile (witch is the 2nd most present profile across the forums); Our vocal member Reinald belongs to one of the psychological subtypes of the "mad sysadmin" profile; Tom, which said yesterday that he would not be interested in rolling Fedora, into third profile, etc. BTW, personally I think, the uncle Bob profile currently most suffers the lack of the real package manager interface (at least under Gnome, I do not have a clue for KDE) - I see this issue as one with even high priority for uncle Bob than the lack of smooth upgrade scenario. So, my concrete proposal is to postpone all general discussions for a little, up to the moment when we describe as much as possible in detail let's say 16 Fedora user profiles and sub-profiles (at least on the wiki) and estimate somehow their population (may be along with the project leaders concept about the profiles witch Fedora actually is intended to seek for). Without any data at hand to back the prioritization and approach variant efficiency/suitability claims, I think it looks impossible to be achieved any level of consensus (especially in that list, as you know far better than me). Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Infrastructure announces status.fedoraproject.org
Great, but the link under "Fedora Packages App" should be either undefined or https://apps.fedoraproject.org/packages/, not the current 404-pointing value of "UNKNOWN". BTW, http://www.smolts.org/ returns 503 currently, but I do not know if this is somehow related with "Everything seems to be working" textual status (probably "working" is about the real service, not the front-page which fails at the moment) Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 18.06.2012 14:22, Richard Hughes wrote: On 18 June 2012 12:03, Benny Amorsen wrote: Why testing the daemons? Any daemon which cannot be restarted by systemctl restart foo.daemon is broken already. Try booting a few VMs and then doing "systemctl restart libvirtd.daemon" -- libvirtd restarts okay (hopefully) but all the clients are disconnected and all the VMs are no longer running. This is not entirely true for my current hypervisors (f16) - all VMs, spicec & RDP connections stays live after: systemctl restart libvirtd.service However, I never tried to update qemu-system with live VMs. Kind regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 18.06.2012 12:10, Richard W.M. Jones wrote: On Mon, Jun 18, 2012 at 02:07:08PM +0530, Rahul Sundaram wrote: On 06/18/2012 01:23 PM, Richard W.M. Jones wrote: On Mon, Jun 18, 2012 at 02:10:32AM +0100, Matthew Garrett wrote: On Sun, Jun 17, 2012 at 06:49:43PM +0100, Richard W.M. Jones wrote: You're asserting that dbus-daemon etc cannot be restarted, but without saying why. Because designing an asynchronous messaging bus that can be restarted without losing any messages is a difficult problem. If only Red Hat was involved in writing one ... Oh wait, what's this? https://qpid.apache.org/ Unless, you can change d-bus to do this while retaining the features, it isn't very relevant to the discussion. What we shouldn't do is break things further by making almost all updates require a reboot. I believe there is or was an effort to replace dbus by something AMQP-based. However I can't find that right now. Probably it is doable on top of ZeroMQ too (+ few bits sqlite around the restarts) and IMO zmq is relatively closer to dbus compared to AMQP. But it is possible to rework dbus in any of these ways (inject persistence, adopting different messaging core) in the F18 timeframe? May be we should look at the proposed feature as unfortunate temporary workaround for the problem introduced by accident in the past, which should be properly addressed for F19. As I understand the proposal, the necessary workaround only affects the desktop instances and specifically Gnome ones - I am under the impression that my servers will continue to be updated by the normal way. Kind regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Total size of Fedora source
Bunch of random strings somewhat related to your proposal: Build: * Assuming loaded source DB (during distribution build) * Source query: pkg:gnome-keyring[@fgit='3f7ff7']//cfunc:gkm_rpc_log/trans-calls::*/arg:line/c:string/string() (All string "line" [1] literals used in calls (direct and transitive) to gkm_rpc_log [**]) * Filling the err-message grammar (snippet from [3]): err-message = "WARNING: " "gnome-keyring" ":: " ( ... | "couldn't secure socket: " everything | "couldn't connect to: " everything ": " everything | "couldn't send socket credentials: " everything ... ) (the grammar is needed for parsing the user input for points 1st and 3rd of your note (see also [***] alternative)) Runtime: * parse the user/service query "WARNING: gnome-keyring:: couldn...": applying the above gremmar and rendering part of the syntax tree in response. Kind Regards, Alek [*] Let's forget for a minute about the fact of hundreds different patters in the whole codebase, let's pretend that we have to handle just the sample error message from your propsal ;-) [**] Imaginary xpath/xquery-like language for code queries ([4,5,6] - leading large scale implementation AFAIK): pkg: pacakges namespace 3f7ff7: 3f7ff7289907d2a27912909e63908eadb16d97bf == 3.2.1-3: Current F16 git for gnome-keyring - implies upstream 6d5818 [2] cfunc: C functions namespace trans-calls: transitive calls axis (like ancestor-or-self but for "calling" relation instead of "nesting" tree relation) arg: argument names namespace c: C language constructs namespace string(): in xpath string() function tries to convert the context tree node to string scalar [***] Less elegant, but also less complicated (we do not need grammar and parsing, but just code-point _key_ matching) option is to convince Tomas to include build instrumentation in the spec (David's gcc plugin based in case of gnome-keyring) for hard error messages pre-enumeration with the following effect: [3] L250 becomes: "[FGKR0TK] couldn't secure socket: %s" [3] L256 becomes: "[FGKR0TL] couldn't connect to: %s: %s" [3] L262 becomes: "[FGKR0TM] couldn't send socket credentials: %s" [1] http://git.gnome.org/browse/gnome-keyring/tree/pkcs11/rpc-layer/gkm-rpc-dispatch.c?id=6d5818#n72 [2] http://git.gnome.org/browse/gnome-keyring/tree/?id=6d58181fcddc5c13762a1920a464787ebc27d4bc [3] http://git.gnome.org/browse/gnome-keyring/tree/pkcs11/rpc-layer/gkm-rpc-module.c?id=6d5818#n246 [4] http://www.lug-erding.de/vortrag/Purely%20Relational%20XQuery%20LUG%20Erding.pdf [5] http://hackage.haskell.org/package/Pathfinder [6] http://dev.monetdb.org/hg/MonetDB/file/f7d6c302cc9c/pathfinder/compiler/algebra/algebra.c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Total size of Fedora source
On 18.05.2012 16:38, Pádraig Brady wrote: An online equivalent to http://livegrep.com/ would rock :) At least ;-). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Total size of Fedora source
Hi Rich, On 18.05.2012 15:49, Richard W.M. Jones wrote: The reason is that I want to check out all the source for an experiment, and I need to know what order of disk space I will need [:-)] Would you like to elaborate - What kind of experiment you are preparing? [Asking because I live with the idea about Fxx-snapshot mass source indexing/XRref for long time already (based mainly on the great David Malcolm's gcc-python-plugin, the openjdk compiler and several other tools) and if your work will be in the same direction I am willing to take part of the tasks - e.g. DBs related work ...] Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
