Re: Flock proposals now open for community voting
On Tue, 4 Jun 2013 10:16:22 -0400 Przemek Klosowski przemek.klosow...@nist.gov wrote: On 06/04/2013 10:02 AM, Tom Callaway wrote: On 06/04/2013 09:55 AM, Lennart Poettering wrote: What's even weirder is that some folks are explicitly mentioned (such as Jon Masters) in the descriptions, so the playing field isn't actually that levelled after all? Only people who refer to themselves by name in their own abstracts (or describe themselves in such a way that it is obvious who they are) ended up like this. We honestly didn't think that was going to happen. This was an experiment. If it doesn't work, we don't have to do it again. In general, it's not surprising that the author often could be divined from the abstract---after all, they are going to talk about their own project (e.g. Lennart on systemd, Ajax on X driver infrastructure, Dan Walsh on SELinux, etc). There just doesn't seem to be a way to avoid that, and besides, past reputation does predict future performance. It's for the editorial board to implement a diversity policy by inviting the young'uns, if they wish so. I disagree - this lets people judge proposed talks/sessions on what is written. I think it's a good idea and, if nothing else, it is just a good trial. And that's enough. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Differences between mock and koji?
On Tue, 4 Jun 2013 16:52:14 +0200 Simone Caronni negativ...@gmail.com wrote: Hello, I have a package that builds fine in a fresh rawhide mock chroot and not in a koji build. Is there any difference between the two? Here is the error in Koji: + make -j5 LIBPATH=/usr/lib64 -f makefile docs rm -f doc/crypt.pdf *.dvi *.log *.aux *.toc *.idx *.ilg *.ind *.out echo hello crypt.ind latex crypt /dev/null kpathsea: Running mktexfmt latex.fmt make: *** [docs] Error 1 RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.5TWg4P (%build) Bad exit status from /var/tmp/rpm-tmp.5TWg4P (%build) And here is the same step in mock: DEBUG: + make -j4 LIBPATH=/usr/lib64 -f makefile docs DEBUG: rm -f doc/crypt.pdf *.dvi *.log *.aux *.toc *.idx *.ilg *.ind *.out DEBUG: echo hello crypt.ind DEBUG: latex crypt /dev/null DEBUG: latex crypt /dev/null DEBUG: makeindex crypt.idx /dev/null DEBUG: This is makeindex, version 2.15 [TeX Live 2013] (kpathsea + Thai support). DEBUG: Scanning input file crypt.idxdone (345 entries accepted, 0 rejected). DEBUG: Sorting entries..done (3023 comparisons). DEBUG: Generating output file crypt.inddone (396 lines written, 0 warnings). DEBUG: Output written in crypt.ind. [...] Log of the failed koji build: http://kojipkgs.fedoraproject.org//work/tasks/4779/5464779/build.log Command used for mock: mock -v --rebuild -r fedora-rawhide-x86_64 libtomcrypt-1.17-16.fc19.src.rpm Koji uses mock to build pkgs. Mock in Koji is run on systems which are isolated from the network. If there is no network connection then there shouldn't be any difference -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Hosted Usability and Developer Experience
On Sun, 2 Jun 2013 16:39:20 -0400 Rahul Sundaram methe...@gmail.com wrote: Hi On Fri, May 31, 2013 at 6:45 PM, Stephen John Smoogen wrote: Actually I was going to ask the opposite question: Do we still need FedoraHosted? It was created before there was GitHub or Gitorious but frankly we are not funded or staffed to make it bigger and better than it is now. The systems are 2 virtual machines with one as primary and one as fallback. It is not a large set of systems and is made on the backbone of compromises of We won't use FedoraHosted unless you support X VCS system... none of the things that Github or Gitorious or even Savannah has had to deal with :). Yeah. Unless Fedora is going to invest in FedoraHosted and make it a excellent platform for projects, there isn't really much need to keep it at this point. There is no particular advantage to it over Google Code or sf.net or github. The underlying platform being free software isn't enough of an distinction when using distributed vcs. I actually disagree with that. I think freedom of the service does matter. The debacles with google reader and google talk recently should be pointing that up to all of us. While DVCS do remove the possibility of our code getting locked up somewhere it doesn't help us much if our entire workflow is locked up there. For example github's pull-request workflow is very nice for projects with a wide contributor base but it is hard to move away from once you are used to it. When I looked at other options to github I was looking for a similar or comparable workflow and I struggled to find any: - gitorious merge-request is a extremely cumbersome currently - gitlab has(had?) no such concept of public repositories so the idea of someone forking and contributing a patch was not even in the system I think the folks running/writing github are good folks with the right motivations but I've found that a lot of people with the right motivations end up getting weird when money gets tight. It is best not to be in a position where you have to find out about that. So - freedom of infrastructure matters - if for no other reason than making sure that anyone who wants to copy and walk away with their code/issues/tickets/wiki can do so w/o needing to buy any software (or worse yet software they CANNOT buy) I agree with smooge that we're understaffed to make the service everything it could be - but there are places we can be in between and we've made changes recently to make it easier for us to try out solutions w/o impacting every project. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On Wed, 29 May 2013 11:52:04 +0100 Richard W.M. Jones rjo...@redhat.com wrote: Also do we know how many mirrors support byte ranges? We could go all the way and have a relatively large uncompressed database stored on the mirrors, but have the client only access small byte ranges from it. We used to use byte-ranges but what we discovered is how many proxies do NOT support byte-ranges and how quickly that falls apart. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On Wed, 29 May 2013 11:48:14 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Tue, May 28, 2013 at 11:51:21AM -0400, seth vidal wrote: I simply got tired of tilting at that particular windmill when confronted with some particularly egregious cases (see libguestfs sometime). $ rpm -qR libguestfs|grep ^/ /sbin/ldconfig /sbin/ldconfig /lib64/rtkaio/librt.so.1 /usr/lib64/sasl2/libanonymous.so.2 /usr/lib64/sasl2/libsasldb.so.2 this must be in f19 - in f18 I see: /lib/i686/nosegneg/libc.so.6 /lib/i686/nosegneg/libm.so.6 /lib/i686/nosegneg/libpthread.so.0 /lib/i686/nosegneg/librt.so.1 /lib/i686/nosegneg/libthread_db.so.1 /lib/rtkaio/i686/nosegneg/librt.so.1 /lib/rtkaio/librt.so.1 /sbin/ldconfig /usr/lib/sasl2/libanonymous.so.2 /usr/lib/sasl2/libsasldb.so.2 /usr/lib/sse2/libgmp.so.10 /usr/lib/sse2/libgmpxx.so.4 /usr/lib/sse2/libmp.so.3 /lib64/rtkaio/librt.so.1 /sbin/ldconfig /usr/lib64/sasl2/libanonymous.so.2 /usr/lib64/sasl2/libsasldb.so.2 and it was much much worse in the past. To resolve 3 strings we have to download 26 MB of data. Getting rid of filelists seems like a bad idea because they are so useful. Implementing them better on the other hand ... At the moment they are stored in a sqlite database which is bzip2 compressed. The filelists DB for Fedora 18 is 26 MB compressed or 143 MB uncompressed. The sqlite database just stores basically the strings as-is. There are some structures which are better for storing strings that have a lot of common prefixes, such as tries and suffix trees. Actually the sqlite db doesn't just store the strings it stores a table which has a pkg id (a number) then all the files in a specific dir for each row. like: 13960|/usr/share/locale/pt/LC_MESSAGES|gnokii.mo|f 13960|/usr/share/man/man8|mgnokiidev.8.gz/gnokiid.8.gz|ff 13960|/usr/share/doc/gnokii-0.6.31|sample/protocol/ringtones.txt/logos.txt/gnokii.nol/gnokii-ir-howto/gnokii-hackers-howto/gnokii-IrDA-Linux/gettext-howto/TODO/README.libsms/README-siemens/README-ericsson/README-dancall/README-WINDOWS/README-Symbian/README-PCSC/README-MacOSX/README-DKU2/README-7110/README-6510/README-6110/README-3810/README-2110/README/MAINTAINERS/KNOWN_BUGS/FAQ/DataCalls-QuickStart/CodingStyle/ChangeLog/CREDITS/COPYRIGHT/COPYING/Bugs just as an example. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On Tue, 28 May 2013 08:51:03 +0200 Jan Zelený jzel...@redhat.com 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). But it is absolutely NOT TRUE that removing filelists will cause 'yum install /usr/bin/vim' to not work. 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. It might prove helpful to know that background to avoid walking down blindalleys in DNF. Thanks! -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On Tue, 28 May 2013 20:42:13 +0300 Alek Paunov a...@declera.com 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. I'd rather not have filedeps so it doesn't get pulled in for other things in depsolving. 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? * 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? * 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. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trimming (or obsoleting) %changelog?
On Mon, 15 Apr 2013 11:03:34 -0500 Richard Shaw hobbes1...@gmail.com wrote: On Mon, Apr 15, 2013 at 11:00 AM, Toshio Kuratomi a.bad...@gmail.comwrote: If I remember, I tend to trim off changelog entries that are more than two years old once a year for packages that I own. Two years is twice the length of a Fedora EOL cycle and since it grows to three years during the interim, that seems a reasonable distance in the past for people trying to get a quick glimpse of when something might have changed. Would it be difficult to have some part of the build process check to see if there's dates older than 2-3 years and report it somewhere? Preferably somewhere where it will get noticed, but not be obtrusive. createrepo truncates the changelogs in the repodata to some limit - I forget what it is set to in koji. Istr that something like that was made an option in rpm, too. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Wed, 10 Apr 2013 09:24:49 +0200 Jan Zelený jzel...@redhat.com wrote: On 9. 4. 2013 at 12:25:56, seth vidal wrote: On Tue, 9 Apr 2013 11:18:54 -0500 Bruno Wolff III br...@wolff.to wrote: On Wed, Apr 10, 2013 at 00:05:45 +0800, Mathieu Bridon boche...@fedoraproject.org wrote: The current behaviour would be obtained by setting it to 1, and setting it to 2 would already be a positive change as it would allow downgrading a package if the update went wrong. I don't think that is really what you want either. The idea is to keep recently obsoleted updates around, not 2 or 3 versions of everything. The change has some other benefits. Reverting bad updates in rawhide would be easier. You can use yum downgrade instead of having to going look at koji and download builds. Dealing with packages dropping out of repos when moving between test and updates. The latter issue is especially bad with branched during freezes. So - this is just an idea - and not necessarily a good one - but what about moving older pkgs which are not in the initial release repo into an updates-archive repo. We could leave the repo disabled by default and only keep 2 copies of any single pkg name in the repo at a time. That way in the best of all possible worlds you'd have at most 4 copies of a pkg in total: 1 - in the base release 'everything' repo 1 - in updates 2 - in updates-archive I'm not sure this solves the initial problem - downloading new metadata every 6 hours or so ... I wasn't trying to solve that problem. The problem I did solve was the updates repodata growing forever if we keep more than one version of the pkgs in there. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Wed, 10 Apr 2013 08:47:38 -0500 Bruno Wolff III br...@wolff.to wrote: On Wed, Apr 10, 2013 at 09:24:49 +0200, Jan Zelený jzel...@redhat.com wrote: I'm not sure this solves the initial problem - downloading new metadata every 6 hours or so ... Does the metadata really need to be downloaded or just checked to see if it is current? The metadata doesn't get downloaded if it hasn't changed - the problem though is that the metadata DOES change often. Normally everyday. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Wed, 10 Apr 2013 10:53:25 -0400 john.flor...@dart.biz wrote: From: seth vidal skvi...@fedoraproject.org The metadata doesn't get downloaded if it hasn't changed - the problem though is that the metadata DOES change often. Normally everyday. Is there anything that could be done to make it unnecessary to pull the complete metadata for every update? For example, IIRC this is all sqlite data, but what if this was in a plain-text data dump form where something like rsync could be used to efficiently transfer only those bits that have changed. Client CPU time to reconstruct the DB is probably cheaper than the bandwidth. Maybe such a mode would only be used if the DB size exceeded some threshold. You'll have to talk to those folks who are trying to work on a delta metadata format. And rsync is not efficient from a bunch of clients to a mirror server. It would cripple a mirror server in a moment. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Wed, 10 Apr 2013 10:33:43 -0500 Chris Adams cmad...@hiwaay.net wrote: The metadata starts in XML before being loaded into an SQLite DB file, and the XML is in the repodata directory with the DB. However, both are compressed, as they are large. For example, the current updates/18/x86_64 XML is over 34M (5M gzip compressed), and the DB is 41M (9M bzip2 compressed). I'm guessing there are historical reasons why different compression is used; both could be made noticeably smaller with xz (XML to just over 3M, DB to 7M), but that's still a lot of data to download (and there are also other metadata files that have to be downloaded sometimes, especially the filelists.xml.gz, which is 10M gzip compressed). I'm not sure when the XML is downloaded instead of (or in addition to) the DB, but it does appear to happen (I see one example in my mirror server web logs this morning for example). Here's how it works. the xml metadata put together over a decade ago. It is the canonical representation of the metadata. The sqlite was added maybe 8ish years ago as a way of more quickly reading the same data and not eating up so much memory. At the time bzip2 was the new hotness so we used it instead of gz. the primary, filelists and other xml should not ever be downloaded at this point unless you hit a mirror which is out of sync, badly. the only xml files that should be getting downloaded: 1. repomd.xml - it's fairly small and the index for everything else 2. comps.xml (or groups.xml) - which is where comps is stored per-repo 3. updatemd.xml which is just the security/update info for describing updates yum will grab repomd.xml and look to see if it is newer than what it has already. Then go from there about updating the rest of the metadata. Hope that helps explain it a bit more. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Wed, 10 Apr 2013 12:24:58 -0400 john.flor...@dart.biz wrote: I was thinking there had been some xz integration recently. Maybe that was with the delta rpm support. I don't follow that though since we have a local mirror, there's not much point in rsycing, storing, etc. the deltas. yum and createrepo both support xz now - we can really only do it from f18-f19 iirc - just ot make sure everyone has the required version of yum and friends. I'm not sure when the XML is downloaded instead of (or in addition to) the DB, but it does appear to happen (I see one example in my mirror server web logs this morning for example). I've wondered about that too. I sure hope we didn't add the efficient method on top of the inefficient method, rather than replace it. See my earlier email explaining how that works. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Keeping old versions of packages
On Tue, 9 Apr 2013 11:18:54 -0500 Bruno Wolff III br...@wolff.to wrote: On Wed, Apr 10, 2013 at 00:05:45 +0800, Mathieu Bridon boche...@fedoraproject.org wrote: The current behaviour would be obtained by setting it to 1, and setting it to 2 would already be a positive change as it would allow downgrading a package if the update went wrong. I don't think that is really what you want either. The idea is to keep recently obsoleted updates around, not 2 or 3 versions of everything. The change has some other benefits. Reverting bad updates in rawhide would be easier. You can use yum downgrade instead of having to going look at koji and download builds. Dealing with packages dropping out of repos when moving between test and updates. The latter issue is especially bad with branched during freezes. So - this is just an idea - and not necessarily a good one - but what about moving older pkgs which are not in the initial release repo into an updates-archive repo. We could leave the repo disabled by default and only keep 2 copies of any single pkg name in the repo at a time. That way in the best of all possible worlds you'd have at most 4 copies of a pkg in total: 1 - in the base release 'everything' repo 1 - in updates 2 - in updates-archive -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Smock successor?
On Thu, 4 Apr 2013 21:18:28 +0200 Till Maas opensou...@till.name wrote: what does 'deterministic repositories' mean? smock uses ~/public_html/smock/$DISTRO/$ARCH by default and mockchain some random temp dir. mockchain uses a tempdir unless you specify -l If you want to add that to mockchain I don't really see a big problem - just felt unnecessary since it can be done with more flexibility at the shell and since mock chroots are not strictly distro+arch but can be a myriad of things. Yes, mockchain is more flexible but smock is more user friendly for it's use case, e.g. the command line is much simpler for this use case. Even if mock chroot are not distro+arch, smock makes a useful assumption/has assumes a useful convention for mock config files. Then hack up a patch to do that in mockchain. It would be worth a look. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Smock successor?
On Thu, 4 Apr 2013 14:47:12 +0200 Johannes Lips johannes.l...@gmail.com wrote: On Thu, Apr 4, 2013 at 2:44 PM, Till Maas opensou...@till.name wrote: Hi everyone, I have been using smock.pl regularly and since it was not developed recently. I wonder what everyone else is using, e.g. does something better exist? If not, I am planning to give it a proper new home, currently I am trying out gitorious: https://gitorious.org/smock/smock/ I think there is mockchain, which should do the same thing, or? https://skvidal.wordpress.com/2012/04/20/mockchain-use-cases-and-examples/ Yes - mockchain exists and is already in the mock package. So you should be able to just use it for that end. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On Thu, 04 Apr 2013 17:29:26 +0200 Vít Ondruch vondr...@redhat.com wrote: Dne 4.4.2013 16:20, Miloslav Trmač napsal(a): esthetics. May be I misunderstood the thread, but wasn't this the main point since the beginning? To prevent the naming-with-version exploit as is still stated in the $SUBJECT? 'exploit'? You really need to choose your language more carefully. exploit is reserved for security issues. In this context using it is just inflammatory and counter-productive. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Smock successor?
On Thu, 4 Apr 2013 18:25:56 +0200 Till Maas opensou...@till.name wrote: On Thu, Apr 04, 2013 at 08:50:43AM -0600, Nathanael D. Noblet wrote: On 04/04/2013 06:44 AM, Till Maas wrote: Hi everyone, I have been using smock.pl regularly and since it was not developed recently. I wonder what everyone else is using, e.g. does something better exist? If not, I am planning to give it a proper new home, currently I am trying out gitorious: https://gitorious.org/smock/smock/ Hello, I still use smock with some modifications (patched to build different distro/arches in threads). I think I also modified it to sign the packages it builds (asks for the key when I kick off a build)... Can you provide the patches? Adding support to sign packages is something I want to look into as well. Seriously, if you want to look at that - please take a look at adding them to mockchain (or mock directly) It's a codepath that's in more regular use at this point and since it is already in the mock package is more likely to be maintained. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Smock successor?
On Thu, 4 Apr 2013 18:25:56 +0200 Till Maas opensou...@till.name wrote: On Thu, Apr 04, 2013 at 08:50:43AM -0600, Nathanael D. Noblet wrote: On 04/04/2013 06:44 AM, Till Maas wrote: Hi everyone, I have been using smock.pl regularly and since it was not developed recently. I wonder what everyone else is using, e.g. does something better exist? If not, I am planning to give it a proper new home, currently I am trying out gitorious: https://gitorious.org/smock/smock/ Hello, I still use smock with some modifications (patched to build different distro/arches in threads). I think I also modified it to sign the packages it builds (asks for the key when I kick off a build)... Can you provide the patches? Adding support to sign packages is something I want to look into as well. Seriously, if you want to look at that - please take a look at adding them to mockchain (or mock directly) It's a codepath that's in more regular use at this point and since it is already in the mock package is more likely to be maintained. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Smock successor?
On Thu, 4 Apr 2013 18:30:02 +0200
Till Maas opensou...@till.name wrote:
On Thu, Apr 04, 2013 at 09:34:22AM -0400, seth vidal wrote:
On Thu, 4 Apr 2013 14:47:12 +0200
Johannes Lips johannes.l...@gmail.com wrote:
On Thu, Apr 4, 2013 at 2:44 PM, Till Maas opensou...@till.name
wrote:
I have been using smock.pl regularly and since it was not
developed recently. I wonder what everyone else is using, e.g.
does something better exist? If not, I am planning to give it a
proper new home, currently I am trying out gitorious:
https://gitorious.org/smock/smock/
I think there is mockchain, which should do the same thing, or?
https://skvidal.wordpress.com/2012/04/20/mockchain-use-cases-and-examples/
Yes - mockchain exists and is already in the mock package. So you
should be able to just use it for that end.
Is it intended to be feature complete? Smock looks more like a simple
build system, because it supports to build multiple archs/distros at
once and uses deterministic repositories and mockchain only supports a
subset of it.
what does 'deterministic repositories' mean?
As to multiple archs/distros at once:
It's a for loop, right?
for distrochroot in fedora-17-i386 fedora-18-x86_64 epel-6-x86_64
do
mockchain -r $distrochroot -l /tmp/myrepo/${distrochroot}/ --recurse
done
If you want to add that to mockchain I don't really see a big problem -
just felt unnecessary since it can be done with more flexibility at the
shell and since mock chroots are not strictly distro+arch but can be a
myriad of things.
-sv
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On Tue, 2 Apr 2013 13:27:43 + (UTC) Petr Pisar ppi...@redhat.com wrote: On 2013-03-29, seth vidal skvi...@fedoraproject.org wrote: What's Architecture good for? To allow multilib. To install more instances of the same version. And yum ignores Architecture on purpose. But don't tell anybody that. Otherwise he could not claim we do not implement parallel installation. Yum ignores arch? Since when? Maybe you're using the word 'ignores' in a way I'm not familiar with. Yes, I used it a little metaphorically. I don't think you're using 'metaphorically' correctly here. Yum doesn't ignore arch and I think you should stop saying that, no matter what sense of the word 'ignores' you think you're using. yum install foo.i386 does exactly what you think it does. yum install foo installs the bestarch is can find for that pkgname. That's exactly the goal. Yum _understands_ architecture. It allows you to install, upgrade, remove architecteruces independetly, yet it allow to substistute one with another one to meet dependencies. Misusing names does not allow all of that. misusing? Is this, again, another metaphor? Please speak plainly. What do you mean here? Where is the misuse? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On Tue, 2 Apr 2013 14:02:46 + (UTC) Petr Pisar ppi...@redhat.com wrote: Or maybe there are APIs 3.8, 3.9, and 4.0 and we want to express (3.8 or 3.9), but poor RPM does not handle `or'? After reading these and other comments from you, Petr, it seems to me you are not interested in making things better, you just want to complain about how you think rpm is not sufficient for what you seem to think is the most important use case. Since you seem to think you're very well versed in the subject area. I'd recommend you pitch in on rpm and dnf development, rather than just pitching unconstructive criticism at them. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On Tue, 2 Apr 2013 14:16:31 + (UTC) Petr Pisar ppi...@redhat.com wrote: On 2013-04-02, seth vidal skvi...@fedoraproject.org wrote: On Tue, 2 Apr 2013 13:27:43 + (UTC) Petr Pisar ppi...@redhat.com wrote: Misusing names does not allow all of that. misusing? Is this, again, another metaphor? Please speak plainly. What do you mean here? Where is the misuse? foo1, foo2, foo3 -- there is no ordering in the upgrade path, you cannot say foo2 or newer. From my point of view mangling package names (see scl_utils) is misuse. There's no ordering b/c those pkgs are not intended to be version-compared to each other. That is, in fact, the goal. If you GOAL is to avoid version comparisons then it is hardly misuse. You should go back and read James' example using shells, it might be easier to understand. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On Fri, 29 Mar 2013 14:01:29 + (UTC) Petr Pisar ppi...@redhat.com wrote: What's Architecture good for? To allow multilib. To install more instances of the same version. And yum ignores Architecture on purpose. But don't tell anybody that. Otherwise he could not claim we do not implement parallel installation. Yum ignores arch? Since when? Maybe you're using the word 'ignores' in a way I'm not familiar with. yum install foo.i386 does exactly what you think it does. yum install foo installs the bestarch is can find for that pkgname. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On Fri, 29 Mar 2013 14:42:14 +0100 Jan Zelený jzel...@redhat.com wrote: On 29. 3. 2013 at 13:22:40, Petr Pisar wrote: On 2013-03-29, Jan Zelený jzel...@redhat.com wrote: In this case we proposed another solution which was turned down (I'm not sure exactly why): Each package requiring multiversion support would have all these versions almost the same as they are right now. The only difference would be that there is a metapackage pointing at all time to the latest version. Because metapackages are considered evil in Fedora (I'm not sure exactly why). To be perfectly honest I don't know either. But I already have half a dozen use cases on my table where metapackages can help. Perhaps it's time to re- consider this policy? Metapackages have, in the past, been a problem b/c most folks were using them in place of comps groups. The usage you're describing doesn't sound like the end of the world but go through a test set of what happens when someone adds obsoletes/provides to a metapackage. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On Fri, 29 Mar 2013 14:40:35 +0100 Jan Zelený jzel...@redhat.com wrote: This is very valid concern. However I'm not sure it's something that can be solved just by the multiversion support in rpm/yum, there are more pieces here to be put together. My first impression of this is that someone screwed up - either upstrem by breaking API or maintainer by pushing the update without consulting stakeholders beforehand. Again I don't beleive multiversion support can solely solve this problem, can it? In my opinion multiversion is solution. From practial as well as theoretical point of view. You cannot dismiss reality just by blaming insufficient communication. Have you seen GTK or Python? I do not expect everybody will utilize multiversion once it will be available. But it's really pain to live without it when it's needed. But we don't live without it, we do have multiple versions of single packages in Fedora, they are just not super-pretty. See my proposal of metapackages. Do you think it would improve the situation? And if you think it wouldn't, could you specify why? We've been doing multiple versions for longer than that. Ultimately the kernel is multiple versions and it has no weirdness with the name. The trick is that the files owned by the kernel pkgs never overlap one another. If the packagers want to build pkgs which never touch one another then you can expand the installonlypkgs option in yum to include other types of pkgs and handle it. but the packaging rigor is quite extreme. /usr/lib/somepkg/2.1/ /usr/lib/somepkg/3.1/ and there must be no other files outside of there or if there are they cannot overlap each other unless the files are ALWAYS IDENTICAL. But if you do that you have to be very specific and very careful with obsoletes. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, 15 Mar 2013 11:33:24 + Daniel P. Berrange berra...@redhat.com wrote: On Fri, Mar 15, 2013 at 07:16:27AM -0400, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. Heh. That's one of the things I love about DNF. No longer having to wait a long time for repo downloads when runing 'dnf' because the cron job has already cached it, is great. I wish yum would do this by default too! There's a yum-cron package. It did just that for years. that's where dnf got the idea. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, 15 Mar 2013 15:11:28 + Daniel P. Berrange berra...@redhat.com wrote: On Fri, Mar 15, 2013 at 09:55:57AM -0400, seth vidal wrote: On Fri, 15 Mar 2013 11:33:24 + Daniel P. Berrange berra...@redhat.com wrote: On Fri, Mar 15, 2013 at 07:16:27AM -0400, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. Heh. That's one of the things I love about DNF. No longer having to wait a long time for repo downloads when runing 'dnf' because the cron job has already cached it, is great. I wish yum would do this by default too! There's a yum-cron package. It did just that for years. Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Go back far enough and it was enabled by default. It was removed from yum when yum was taken in for rhel b/c, iirc, interaction with rhn and then wanting yum-updatesd. I may be misinterpreting your tone in these emails but you sure seem to be somewhat angry about this... I have no idea why, though. this is my last comment on this thread. I'm glad you like the feature in dnf. I'm sure the dnf devels are happy about it too. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Fri, 15 Mar 2013 11:58:33 -0400 (EDT) Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Daniel P. Berrange berra...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, March 15, 2013 11:48:41 AM Subject: Re: dnf installs cron.hourly On Fri, Mar 15, 2013 at 10:45:03AM -0500, Jon Ciesla wrote: On Fri, Mar 15, 2013 at 10:30 AM, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 15, 2013 at 4:11 PM, Daniel P. Berrange berra...@redhat.com wrote: Users shouldn't have to go searching out that kind of thing in a separate package IMHO, it could just be part of stock yum install. If it needs to be optional a config param would suffice, rather than the big hammer of installing/uninstalling extra RPM to enable/ disable a feature. Yeah, we don't generally do configuration by package installation/uninstallation. More to the point, https://fedoraproject.org/wiki/Starting_services_by_default That's about starting system services by default though, so isn't directly relevant to the question of whether cron jobs are allowed to be enabled by default. Do we have any package docs about cron job enablement ? I couldn't find any in my search attempts. Daniel The list of files sitting in my /etc/cron.*/ directories would certainly indicate that even if there is such a rule it is being ignored. Not that I necessarily have a problem with that given the jobs that are there (mlocate, cups, logrotate, man-db are all examples I don't remember setting up myself). To be fair - none of those call out to the network. they all act on things locally. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 13 Mar 2013 14:52:37 -0400 Daniel J Walsh dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks = 0 I apologize for the ignorance - but what do these _do_. (please don't say they protect your hardlinks and symlinks) - I mean what does 'protected' mean in this context. thanks, - -sv -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iD8DBQFRQMvB1Aj3x2mIbMcRAq1sAJ93c0UxBsYkkjD/vOA4mlDV+x854ACfdeF0 L0XiZMhSMEV546f2616NGBM= =kxi7 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11 Mar 2013 18:55:30 +0100 Alec Leamas leamas.a...@gmail.com wrote: Fine with me, but don't forget to have a hint to this key visible e. g., Press F1 to... in some corner. Current policy that user just should know the key is not that good IMHO. After all, this is the first screen a newcomer meets. And thisis not only about the initial grub boot but also the main boot process (and screen) that follows. I really do like the idea of a line which says: Press some key to see what's going on right now It creates a learning opportunity for new users and a relatively benign way to present this info. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11 Mar 2013 14:49:10 -0500 Michael Cronenworth m...@cchtml.com wrote: On 03/11/2013 02:41 PM, Björn Persson wrote: Yes, why not display the Grub menu? Because it's the year 2013. Not 1999. There's no need for this kind of sarcastic/snarky response. I don't think Bjorn was asking an unreasonable or rude question. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11 Mar 2013 21:07:32 +0100 Lennart Poettering mzerq...@0pointer.de wrote: I don't think we should generate any message. Nothing at all. My BIOS doesn't print a single line, and neither does the kernel if quiet is used (which is the default). I really don't see why Plymouth or the boot loader should print any more -- unless a real problem happens, or the user explicitly asked for more, or the boot takes very long. Entering the boot loader is something that is a debugging feature, a tool for professionals. It shouldn't be too hard to expect from them to remember something as simple as maybe press shift or Space or Esc to get the boot menu or more verbose output. I mean, honestly, that's probably what most people would try automatically anyway if they want feedback from the machine. I'm mostly concerned with making new professionals. We have to make the secret information discoverable if we want people to poke and prod around. If the bioses and systems years ago had been opaque we wouldn't have gotten this far. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11 Mar 2013 22:00:54 +0100 Lennart Poettering mzerq...@0pointer.de wrote: I'm mostly concerned with making new professionals. Well, where do you get them from? Here's a hint: the Unix market is now all ours, so you can only get them from Windows. And on Windows 8 they don't have any pointless sleeps in the boot, and if you want a boot menu, you have to press something. New professional get made from kids learning. From folks tinkering in basements and on their free time. It's not all structured learning. It never has been. We can even use the same key as windows does, if that helps you... I just want something discoverable, best if it were printed out and obvious. If the bioses and systems years ago had been opaque we wouldn't have gotten this far. Which is nonsense. Citation needed. It is not self-evidently nonsense. Please don't be this way. Also modern EFI systems work the same way. I mean, they are even more drastic in many cases, and don't initialize USB kbds at all anymore, so that you have to go through the OS to get back into boot menu. You're making an argument why EFI is trying to make computers devices that people only consume with, not devices they learn and create with. I don't think we should be encouraging this behavior just b/c others are. Your same argument could be used to justify not releasing source code, too. Please justify what you're arguing for. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11 Mar 2013 17:05:31 -0400 Máirín Duffy du...@fedoraproject.org wrote: Hi Seth, On 03/11/2013 04:20 PM, seth vidal wrote: I'm mostly concerned with making new professionals. We have to make the secret information discoverable if we want people to poke and prod around. If the bioses and systems years ago had been opaque we wouldn't have gotten this far. How do you feel about Ryan's suggestion to make grub appear on any key press (instead of having it mapped to any one specific key?) My initial reaction is this: if I see a press any key to see what's happening right now - then I know what pressing a key will achieve. if I don't see anything like that - then I may be in for a bit of a scare. I want to encourage kids, teenagers, etc to explore the OS. We need them to be involved in CREATING and LEARNING. So I don't want to scare any of them off. Is one line of text really that significant of a problem to present? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11 Mar 2013 16:18:33 -0500 Michael Cronenworth m...@cchtml.com wrote: On 03/11/2013 04:13 PM, seth vidal wrote: I want to encourage kids, teenagers, etc to explore the OS. We need them to be involved in CREATING and LEARNING. So I don't want to scare any of them off. My OLPC does not present any boot menu or prompt. That's not an argument for why we should not present one. It is an argument for why they should be. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11 Mar 2013 15:24:28 -0600 Chris Murphy li...@colorremedies.com wrote: If the bioses and systems years ago had been opaque we wouldn't have gotten this far. Please elaborate on this, and define this far. Apple has had fairly opaque booting for ~28 years, so I'm curious how much farther they need to go. 'this far' - developing an os. Developing an OS without closed/restricted/special access to professional documentation on the platform. Apple builds their own hw and can hire people to work on their problems with their infinite pile of money. We need to recruit people into being interested in linux. Take a look at the age demographic of a lot of linux kernel/distribution maintenance folks. We're skewing to an older cohort. We need to make it possible for others to be involved. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, 11 Mar 2013 17:34:28 -0400 Ryan Lerch rle...@redhat.com wrote: I think the suggestion in this thread is to simply keep a key *pressed down* that way there are no issues with the user having to time a keypress. Having a key pressed down helps, also, with Accessibility for folks with precise timing issues in motor control. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Tue, 05 Mar 2013 13:07:59 -0500 Colin Walters walt...@verbum.org wrote: On Tue, 2013-03-05 at 12:44 -0500, Stephen Gallagher wrote: Well, in that case I suppose we'd need to add a new tag-set, something like rawhide-pending In other words, another layer. I'll only repeat this maybe every 6 months or yearly, depending on how annoying people find me. But basically, the #1 problem is the inability of RPM to go backwards (i.e. versions must always go up). It's like a car with no brakes and no reverse gear, driving down a road that's being dynamically built in front of it. A lot of times, the correct response to stuff just broke! is revert. Not just revert - revert *quickly*. Don't let the master tree be broken. Don't go off a cliff just because someone put a wrong sign on the road. For example, let's say a new version of Mesa breaks GNOME with llvmpipe. One really can't fault the Mesa maintainers, because it's quite possible they tested it, just on the Intel or AMD hardware on their laptop. But the correct response here is still to revert to the previous Mesa until the problem is found and fixed. If instead what we have is another layer/repo or state of packages, this issue would end up blocking progress on *everything else* into rawhide until it was fixed, because the AutoQA tests would just keep failing. That's very problematic. (This is assuming the AutoQA tests are something interesting and useful like booting GNOME, and not spelling checks for the spec file descriptions or something) But given the drastic changes to RPM (and all the software built on top of it like mock, koji, createrepo, etc.), that would be required to fix this newer is always better problem, I can't fault you for saying we should add another layer. If the issue was only 'newer is better' then rpm can easily get around it. Hell, so can yum, now. The issue is that we have nothing that even resembles a backward-compat process for user DATA. I can roll back package binaries all day long, but if there is a db or config format which has moved on - and been modified -the user is screwed. For fun - try to run a desktop of f16 and f18 using a shared homedir sometime. So - I don't see how adding another layer is really a problem - since the 'infinite versions in every direction' won't help our users losing their configs or worse their data. am I missing something here? Have we solved the user data problem? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Tue, 05 Mar 2013 13:28:58 -0500 Colin Walters walt...@verbum.org wrote: On Tue, 2013-03-05 at 13:17 -0500, seth vidal wrote: If the issue was only 'newer is better' then rpm can easily get around it. Hell, so can yum, now. But koji, createrepo and such can't, right? createrepo is version agnostic. It cares not at all. koji can build whatever, too.. I'm not sure how those are related here. True, but the biggest problems are things like new versions of colord that trip up a selinux-policy denial which then in turn cause gnome-settings-daemon to crash which in turn gives you a failure at GDM. None of that involves user data. gdm does change your user settings when you login, though. For desktop environment selection (or at least it used to) So - I don't see how adding another layer is really a problem - since the 'infinite versions in every direction' won't help our users losing their configs or worse their data. am I missing something here? Yes - that we don't need to solve the user data problem for all software immediately to support rolling back a Mesa upgrade. I'm not sure how much software you're actually talking about here that doesn't end up touching the user somewhere. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Tue, 5 Mar 2013 16:58:49 -0500 Bill Nottingham nott...@redhat.com wrote: seth vidal (skvi...@fedoraproject.org) said: On Tue, 05 Mar 2013 13:28:58 -0500 Colin Walters walt...@verbum.org wrote: On Tue, 2013-03-05 at 13:17 -0500, seth vidal wrote: If the issue was only 'newer is better' then rpm can easily get around it. Hell, so can yum, now. But koji, createrepo and such can't, right? createrepo is version agnostic. It cares not at all. koji can build whatever, too.. I'm not sure how those are related here. Well, on the koji side there are build concerns, but that's somewhat separate from giving users something they can stay on stably. We don't ship in a way that easily allows this though, now. Admittedly, this is due to the sheer *amount* of stuff involved in just maintaining single versions of things, and how much that would jump if we started having multiple versions available all the time. That being said, as long as we're willing to take the hit in disk space repodata size, and we're willing to nuke deltas from orbit (they won't scale to this, sorry), we could certainly support having multiple versions of everything available for easier rollback. Bill Bill, provided the above is not an unfunded mandate - then yes - I think you're right. I don't think we could do it w/o money. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning PycURL
On Sat, 23 Feb 2013, Matthew Miller wrote: On Fri, Feb 22, 2013 at 03:17:57PM -0500, Seth Vidal wrote: it's not under my control anymore - but the idea of python-requests and its deps pulled into @core does not fill me with joy. Sooo $ rpm -qR python-requests|grep -v ^rpmlib\( ca-certificates python(abi) = 2.7 (And ca-certificates doesn't require anything.) It's relatively big for a core package (couple of megabytes, give or take). And curl is required by a number of *other* things, and it's pretty nice to have such a utility in standard if not in core at least, so it's almost free as a base. Does requests still have some local copy of other libs? Apparently it doesn't pull them in from other packages. :) See Pierre's msg following this - the issue is what it bundles. But the yum devs can make a decision on what they want to do with urlgrabber. Not sure what dnf is using at the moment. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning PycURL
On Fri, 22 Feb 2013, Pierre-Yves Chibon wrote: On Fri, 2013-02-22 at 12:02 -0800, Samuel Sieb wrote: On 02/22/2013 10:02 AM, Jeffrey Ollie wrote: Personally, I'd like to see Yum move away from PycURL but if someone wants to take over upstream development more power to them. I use pycurl as well. Do you have a suggestion for an alternative package to use that has similar capabilities? requests? Or plain urllib although it remains quite painfull. it's not under my control anymore - but the idea of python-requests and its deps pulled into @core does not fill me with joy. Does requests still have some local copy of other libs? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning PycURL
On Fri, 22 Feb 2013, Jon Ciesla wrote: I'm not familiar with it, nor is it in Fedora yet, but would curlish work? https://pypi.python.org/pypi/curlish/ It's calling out to curl via subprocess - that doesn't feel like a good idea -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
On Fri, 25 Jan 2013, Honza Horak wrote: On 01/23/2013 01:04 PM, Ales Kozumplik wrote: On 01/22/2013 10:06 PM, Tom Lane wrote: Yes, that's the general idea --- any dependencies on mysql should result in installing mariadb, unless the user takes specific action to get mysql instead. Ideally we'd just do the standard Provides/Obsoletes dance for replacing one package with another, but I'm not quite sure how that should work if we still want original mysql to be installable. Any thoughts from RPM experts would be welcome. I'm not an RPM expert, yet if mariadb obsoletes mysql and mariadb is installed then specifically selecting mysql package for installation will not be possible (because it is obsoleted). This is true, switching back to mysql wouldn't be easy for users. I haven't tested this one yet, but I guess they will be able to do it in two steps: * remove all mariadb packages * install mysql with excluding mariadb explicitly A bad thing is, that they will have to re-install even other depended packages, which have been removed during mariadb removal. Is there really no way to do removal/install like above in one yum transaction? yum shell remove foo install bar run -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Syslinux Option
On Thu, 24 Jan 2013, Miloslav Trmač wrote: On Wed, Jan 23, 2013 at 8:30 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Features/SyslinuxOption = https://fedoraproject.org/wiki/Features/SyslinuxOption Feature owner(s): Matthew Miller mat...@fedoraproject.org This feature will make Syslinux an optional bootloader for Fedora, in kickstart and via a hidden Anaconda option. When used this way, it will replace grub2. So, to summarize, this saves = 6 MB of disk space, and = 1 second of boot time, at the cost of extra maintenance and QA burden in anaconda and grubby? I'd love to hear what anaconda developers and Fedora QA think about this trade-off. Is there perhaps a consensus what the long-term future will look like? In particular, is it impossible/plausible/probable that most architectures will move to EFI, and if so, will virtualization also move to EFI eventually? That would mean syslinux is not a long-term option. Or is the future in this area uncertain enough that there is a benefit in having more options readily available? I think the benefit is for the cloud instances (of which there will be considerably more than hw-installs) that don't need the features or complexity of grub - not too mention all the deps it pulls in, iirc. that's the benefit. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Something is killing my Koji build
On Fri, 11 Jan 2013, Kevin Fenzi wrote: On Fri, 11 Jan 2013 12:16:50 + Daniel P. Berrange berra...@redhat.com wrote: On this theme, one other very useful thing we could improve in Koji for developer debug of failed builds, would be to capture the 'config.log' file from any autoconf based builds. Currently when I get stuck with configure problems I have to hack the spec file todo %configure || cat config.log. It'd be nicer to have config.log as a standalone published file though, because sometimes you have a successful build but later want to go back and see why configure chose a particular thing and you're lacking config.log at that point. Perhaps this is something mock could be enhanced to do? Then koji would (mostly) get it by default from mock... Could probably be easiest done as a mock plugin. Have it look for a config.log in the build dir and have it pull it out to the results dir. Not sure what it would do in the even it found more than one, though. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, 10 Jan 2013, Matthew Miller wrote: On Thu, Jan 10, 2013 at 01:28:01PM -0600, Chris Adams wrote: On Thu, Jan 10, 2013 at 09:29:43AM -0600, Greg Swift wrote: maybe i'm weird too, but ya.. i use finger more than who I think alias in your bashrc is the answer here. :) finger and who don't do the same thing, so an alias isn't going to help. Well, it may help enough. Or alias it to getent if that's what you're looking for. Or, if nothing is close enough: alias finger=echo Don\'t do that. But finger can still be installed on the multiple-user systems that still persist, or in any environments which still run finger servers. (Are there any?) I think the case is pretty good that it's obsolete. Fun fact™: I learned from this conversation that my default personal user environment still contains a .plan file. What was in your plan? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, 10 Jan 2013, Matthew Miller wrote: On Thu, Jan 10, 2013 at 02:46:08PM -0500, Seth Vidal wrote: Fun fact™: I learned from this conversation that my default personal user environment still contains a .plan file. What was in your plan? I can't tell you. It's a Secret Plan. (That's what it says. I'm pretty sure it dates back to 1993 when I got my first VAX account.) I used to have a .agenda file so I could tell people I had a hidden agenda. :) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback wanted: Fedora Formulas
On Wed, 9 Jan 2013, Kevin Fenzi wrote: One of the big questions to answer is distribution. I can see good arguments on the one hand distributing formulas via RPM and on the other having an official Git repository for them. Yep. I am torn here too. rpms get us a lot, but are also inflexable in other ways. :) Let me make an argument against rpms here. Ansible doesn't require anything on the local system to run a playbook. That's one of its virtues. For a user if we just use a git repo then the user doesn't have to modify their system in order to use the tools to change their system. There is a certain amount of elegance in that not to mention just not being annoying. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback wanted: Fedora Formulas
On Wed, 9 Jan 2013, Bill Nottingham wrote: Seth Vidal (skvi...@fedoraproject.org) said: One of the big questions to answer is distribution. I can see good arguments on the one hand distributing formulas via RPM and on the other having an official Git repository for them. Yep. I am torn here too. rpms get us a lot, but are also inflexable in other ways. :) Let me make an argument against rpms here. Ansible doesn't require anything on the local system to run a playbook. That's one of its virtues. For a user if we just use a git repo then the user doesn't have to modify their system in order to use the tools to change their system. There is a certain amount of elegance in that not to mention just not being annoying. Well, if we're allowing this to be for end-users as opposed to just managed infrastructure, it would require *something* to be on the local end-user's system, depending on how the playbook is written. (For example, if it uses the 'command' or 'shell' features) That can be mitigated by having requirements on the playbooks that we accept into this repository, of course. 1. you don't want to use command/shell modules much - mainly b/c they are not idempotent and get run every time barring the presence of the creates=option 2. you are correct that if you are using something not commonly on systems in a command or shell module you're in trouble. However, you can pull those in an early step in the playbook w/o controversy. Playbooks don't execute in random order. They are in a strict, obvious order. does that help? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, 6 Dec 2012, Jan Zelený wrote: Well, not exactly, you would still need to upgrade all packages that the new version of Libreoffice depends on and all packages these updated packages depend on and so on ... The only difference is that these updated packages would need to be a part of the collection while keeping the rest of the system intact. However the maintenance burden would be even higher, as maintainers would need to take care of multiple versions of packages in each Fedora. Bottom line, the final effect for user wouldn't be much different from current state of things (in fact it might get even more complicated by the non-trivial way how programs in collections are executed). Therefore this isn't exactly the use case SCLs try solve. I find it interesting that we've not really named the use case that SCLs are trying to solve for. It appears to be for the case of a developer who wants to run against a specific version of something (normally a language or module for that language) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, 6 Dec 2012, Jan Zelený wrote: The original use case for SCLs is to provide a way to deliver newer versions of SW in stable distributions like RHEL/CentOS than those available in the core system and make sure system packages and collection packages don't collide in any way (names, libraries, system paths, ...). right and the motivators for the above are customers/users who have to deal with their developers complaining about wanting a specific/newer/older/intermediate version of some language or another and its modules. they complain to their ops people, they complain to fedora/red hat. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What would it take to make Software Collections work in Fedora?
On Thu, 6 Dec 2012, Jan Zelený wrote: Hi, I guess the main reason why SCL is not used in Fedora it requires a certain (potentially non-trivial) amount of work from package maintainer. However feel free to make your packages SCL enabled. You shouldn't have any issues with that. Just make necessary modification in your spec files, build all packages against the Fedora in which you want them and host them in your repo. The only inconvenience here is that Fedora infrastructure isn't yet prepared for simple support of private repositories in a style of Launchpad so you have to do all this work manually. Bohuslav and I are working hard on making the copr code ready. http://git.fedorahosted.org/cgit/copr.git and very soon we're going to need more help. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, 13 Nov 2012, Matthew Miller wrote: On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote: On Tue, Nov 13, 2012 at 4:41 PM, Bill Nottingham nott...@redhat.com wrote: [list of packages] ntpdate chrony On EC2 (as in many virt environments) the hardware clock source is actually synced and running an ntpd service on the client is redundant. I would say this is not accurate. My experience with the instances running under xen is that that is true. My experience with the instances running in euca under kvm is that that is not true. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Matthew Miller wrote: Okay, cool -- there's a lot of enthusiasm for a SIG for the core package set. So, first up on the SIG goals: clarifying our target. It's been suggested before that there's so many possibilities that this is useless, but the point here is to *pick* a reasonable choice as a group and to work with that (even if we can't get complete consensus). Then, later, when someone says but minimal could mean so many differen things! we simply say sure, but *this* is what we mean. I see three basic options for the target: A) kernel + init system and we're done B) boot to yum (with network): a text-mode bootstrap environment on which other things can be added by hand (or by kickstart) C) a traditional Unix command line environment with the expected basic tools available To me, 'C' is too wide for two reasons. First, it's too open for continual debate, because different people might expect different tools. Second, it's not necessarily the right base for the rest of the distribution, because many use cases might not really need that traditional Unix environment. I think 'A' is interesting and useful, but I don't think it should be our target, because it's not *useful enough*. We may want to eventually define a sub-group which covers just this tiny base (maybe with busybox?), but I think that's a different project. So that leaves me at *mostly B*, although I have some sympathy to the idea that we should include a few other things like a man page reader, since we're installing man pages, and a way to deliver e-mail to root, since we're installing things that send such mail. And I think the core environment should include ssh, but I'm open to the idea that even that should be an add-on. What do you think? I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ ditto w/rsync. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Tomas Mraz wrote: On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote: On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ Perhaps scp could be moved to the base openssh package then. Sounds reasonable to me. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Dennis Jacobfeuerborn wrote: On 11/12/2012 06:03 PM, Seth Vidal wrote: On Mon, 12 Nov 2012, Tomas Mraz wrote: On Mon, 2012-11-12 at 11:37 -0500, Seth Vidal wrote: On Mon, 12 Nov 2012, Matthew Miller wrote: On Mon, Nov 12, 2012 at 11:29:34AM -0500, Seth Vidal wrote: I think ssh has to be in the mix. Of ths systems I use/maintain/etc very few of them are ones I actually have a reliable console to. If ssh isn't there, I have to add it just to get the system set up. Yeah: if we get to the point where every real install has to add the same subset of packages to core, I don't think we've succeeded in doing anything except make more work for the whole world. A cron daemon and (at least basic) MTA fall in the same area, I think. But what about ssh-clients? Is there a reasonable yardstick rule we can make, or is it pragmatically best to just make per-package decisions? so - imo openssh-clients is required, yes - b/c w/o them scp doesn't work. :-/ Perhaps scp could be moved to the base openssh package then. Sounds reasonable to me. Not sure that's a good idea. ssh itself is also part of the clients package and should probably moved as well then. sftp is probably popular too. I think its better to bite the bullet and just include the clients package as a whole. i think you misunderstand. if I am attempting to connect to a server running sshd: I can run ssh servername and that works I can run sftp servername and THAT works I cannot run scp servername I have to have a local scp client installed on the server for scp to work as a service. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Petr Lautrbach wrote: scp is a ssh client. It connects to other host using a ssh connection and runs 'scp -t' or 'scp -f' commands on the remote side. From my point of view, it's same as any other program you can use via ssh and I believe that openssh-clients is the right place for it. sftp subsystem is configured by default so you can use it if you need transfer files to minimal system. which was, in fact, what I said. scp is something people expect to be able to use on servers to send files over. that it is not there makes the server install feel a touch awkward. that's all. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Petr Lautrbach wrote: which was, in fact, what I said. scp is something people expect to be able to use on servers to send files over. that it is not there makes the server install feel a touch awkward. that's all. A thin client would probably not want to install openssh-server. fantastic. show me a deployment somewhere of a 'thin client' that doesn't use their own custom kickstart/pxe for instantiating the clients and that will be relevant to this discussion. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Jesse Keating wrote: On 11/12/2012 12:17 PM, Matthew Miller wrote: On Mon, Nov 12, 2012 at 12:08:38PM -0800, Jesse Keating wrote: To be fair if we're talking about redefining what goes into @core (which cannot be deselected, and mandatory items cannot be deselected) then even those doing kickstart/pxe are relevant to the discussion. Is it now the case that they can't be deselected with - in kickstart? Historically the @core group did not have anything other than mandatory packages as there was no UI to deselect them (because core was not a visible group). Core is still not a visible group, but there appears to be a few default packages in there now, NetworkManager, ppc64-utils, and sendmail. I'm not sure of the backstory on this, but now you can - those packages (provided nothing else requires them). More of @core could be made this way, if that was desired for the kickstarters. sendmail is in there so we didn't need a special case to make sendmail 'win' for the options for MTA. ppc64-utils is b/c I do not think we had another way to get it in for the ppc boxes. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12 Nov 2012, Benny Amorsen wrote: Seth Vidal skvi...@fedoraproject.org writes: fantastic. show me a deployment somewhere of a 'thin client' that doesn't use their own custom kickstart/pxe for instantiating the clients and that will be relevant to this discussion. Is kickstart installs generally out of scope for minimal package set? The problem used to be that even with kickstart, you ended up with a too-large package set which you then had to rpm -e at the end. Awkward. This has gotten much better, of course. Personally I was hoping that the minimal project would end up making it possible, using kickstart, to install enough to get yum running. Ideally the size of that minimal install would be rather small. The users can always add more... If people want an actual functional system out of the box, it seems that they would be better off with one of the other installation choices. But anyway, if it is possible to prevent the installation of openssh-* in the kickstart file, that is ok with me. rpm -e afterwards, not so much. why is rpm -e in %post in the kickstart not okay? the system isn't 'up'. what harm is it in cleaning up crap? If you're doing enough installs that the bandwidth is an issue in installing these additional packages then you should make a local mirror, I'd think. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: livemedia-creator and the fedora build system [was Re: appliance-creator: how can I ...]
On Mon, 12 Nov 2012, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Sat, 10 Nov 2012 11:12:20 -0500 Matthew Miller mat...@fedoraproject.org escribió: On Fri, Nov 09, 2012 at 07:25:35PM -0800, Brian C. Lane wrote: I think appliance-creator is pretty much unsupported at this point, isn't it? Yes, so moving to ami-creator might be a good choice. livemedia-creator is supposed to replace livecd-creator, appliance-creator and ami-creator, although it hasn't seen much testing for the last 2 cases it does have code that may work :) It is part of the lorax package. I'm told by Fedora release engineering folks that we can't use that -- the builders run in VMs, so virt-install isn't an option, and since livemedia-creator is based around that, it's not available to us. Its not available because ive not yet worked out the magic to be able to create a chroot with the target bits i.e. f18 and run livemedia-creator in the chroot and have it spin up a vm and do the install etc and work as it needs to. Its a case of where the tool was written without thought for the requirements on how it would be run. we have dedicated physical hardware for building the images on. thats not at all the issue. either im not clear in how i explain things or people are only half listening. We could maybe engineer an alternate build process using the internal cloud, adapting livecd creator to run on a cloud instance rather than with virt locally. Or something. Any ideas? On another note, Boxgrinder also is based around appliance creator, and it'd be nice to play nicely with those people too. Boxgrinder is not a viable option at all. agreed - if for any reason than too many moving parts and a giant software stack behind it. Dennis, ami-creator is what I've been using to make imgs for euca and I know it will work for ec2 imgs (provided you have a kernel/ramdisk which works with xen) And ami-creator only requires a dead-standard stock kickstart file. (well you have to do various things in %post to make the img work when it is spun up in an instance but that's nothing different than normal kickstarty-ness. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Sat, 10 Nov 2012, Jesse Keating wrote: On Nov 10, 2012, at 11:21 AM, Kevin Kofler wrote: Jesse Keating wrote: Fedora is just one of the downstream users of Anaconda. It is incorrect to assume that the upstream Anaconda development can be dictated solely by Fedora, any more than upstream RPM development can be dictated solely by Fedora. If you want to be truly independent of Fedora, you need to do your development elsewhere and only import finished and fully working upstream releases into Rawhide (which need to be testable by Alpha and 100% complete by Beta), as for any other upstream project in the critical path. As long as you (ab)use Rawhide to do upstream development and alpha-testing in, Fedora WILL dictate how you do development. Sorry, that's not a hard requirement of any other upstream, and KDE/Gnome have frequently used snapshots in rawhide/branched. Jesse, To be fair - gnome/kde importing something into rawhide/branched that's not finished doesn't shut down everyone else's ability to test the distro I think it is disingenuous to talk about another distro using anaconda - b/c the only other one that does, directly, is rhel - and they're downstream of fedora, too. That doesn't mean things can be dictated - but it does mean that breaking/delaying fedora is not something that should be done lightly. I think holding anaconda to higher standards is not a ridiculous concept. For years the requirement for yum and rpm (even in rawhide) has been 'never commit something so broken it cannot be used to revert itself'. but I'm positive that this conversation is long past the point of productivity so... -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Sat, 10 Nov 2012, Kevin Kofler wrote: Richard W.M. Jones wrote: - depends on Python stack +1, we really need to get Python out of the minimal installation. The focus should be on replacing the existing Python-based packages in the minimum set (e.g. yum) by native replacements (e.g. zif). Adding more Python stuff with additional Python dependencies is a step backwards. I really don't understand why a core system component such as firewalld is implemented in Python! Yum will likely be replaced with dnf afaik. I don't think zif is under consideration at all. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, 9 Nov 2012, Matthew Miller wrote: This perplexing to me. In my %post section, I tried both writing GRUB_TIMEOUT=0 to /etc/default/grub and using sed to replace set timeout=5 in grub2.cfg. I even put a call to grub2-mkconfig to re-write the config file after doing those things. But on boot, grub.cfg file always contains timeout=5. Why / how is this happening? I'm using appliance-creator, in case that's doing anything silly. in your kickstart can you do: bootloader --timeout=1 -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, 9 Nov 2012, Matthew Miller wrote: On Fri, Nov 09, 2012 at 01:33:32PM -0500, Seth Vidal wrote: in your kickstart can you do: bootloader --timeout=1 Forgot to mention: this is already there and does not have any effect _either_. hmmm - seems to work for me using ami-creator. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, 9 Nov 2012, Matthew Miller wrote: On Fri, Nov 09, 2012 at 01:42:58PM -0500, Seth Vidal wrote: in your kickstart can you do: bootloader --timeout=1 Forgot to mention: this is already there and does not have any effect _either_. hmmm - seems to work for me using ami-creator. I'm using appliance-creator because it's what we're using in Koji. Willing to switch if we're up for switching in the builders Not sure these two QUITE do the same thing - but they use the installer similarly, I think. here's what I've been using: https://github.com/eucalyptus/ami-creator -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: appliance-creator: how can I shorten the grub timeout in kickstart?
On Fri, 9 Nov 2012, Matthew Miller wrote: On Fri, Nov 09, 2012 at 01:49:34PM -0500, Seth Vidal wrote: Not sure these two QUITE do the same thing - but they use the installer similarly, I think. here's what I've been using: https://github.com/eucalyptus/ami-creator I've got https://github.com/katzj/ami-creator :) Jeremy's is older last time I checked - the one from euca is modified by andy grimm and, well, works and stuff. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Deploying fedora infrastructure (koji) across clouds
On Thu, 1 Nov 2012, Mo Morsi wrote: Cool thanks for the info Seth. Ansible looks interesting, its a configuration orchestration component akin to Puppet / Chef is it not? Does it do any provisioning in itself? Ansible is more like this: Combining puppet and chef in one item. Then making it so you can run the entire tool w/o having to first setup the config mgmt system on the node and not requiring any sort of central server. So - ansible is those things and it doesn't make install a giant ruby blob on a system. The ec2_create utility on your blog seems to call out to euca2ools to do the actual provisioning on ec2 correct? You'd still want a component such as Deltacloud to abstractify commands to different cloud providers would you not? I doubt it. It's easier to simply use the euca2ools w/the ec2 api against openstack/cloudstack/euca/etc. Or if need be write an ostack_create to use nova. I'm not interested in supporting the whole world of clouds with this - we only have euca and openstack setup - nothing else. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Re: Deploying fedora infrastructure (koji) across clouds
On Thu, 1 Nov 2012, Mo Morsi wrote: Hrm I was refering more to the repos necessary to bootstrap the cloud instance for the koji builder. I see - I thought you were referring to package repos. Which component imposes this limitation on koji, the hub or the builder? the hub. Would being able to build custom cloud images on the fly for different clouds assist with this? No - where it is built has nothing to do with it. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Deploying fedora infrastructure (koji) across clouds
On Thu, 1 Nov 2012, Michael Scherer wrote: Le jeudi 01 novembre 2012 à 08:32 -0400, Mo Morsi a écrit : On 10/31/2012 01:07 PM, Seth Vidal wrote: You can orchestrate all of these steps across/between multiple systems using ansible: http://ansible.cc - I've been documenting spinning up and provisioning instances on my blog in the last week or so. You might take a look - it should solve the problem of the above needing to be so manual of a process and it requires nothing other than ssh be installed on the machine you're trying to configure/control. Cool thanks for the info Seth. Ansible looks interesting, its a configuration orchestration component akin to Puppet / Chef is it not? Does it do any provisioning in itself? It can be used for remote and parallel job executation ( like run uptime on all servers ). But it can also be used with playbook, to describe the state of a server and make sure it is compliant. For example, make sure service is started, restart if config was changed ( using a notification system ). Most importantly to me is the ability to orchestrate between servers in a single playbook or via the api: Ex: Take data from running this on system 1 and put that data into the config on system 2, notify system 3 you've done this -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deploying fedora infrastructure (koji) across clouds
// small wrapper script around deltacloud: $ wget https://raw.github.com/movitto/mycloud/master/mycloud.rb $ chmod +x mycloud.rb // template describing kojihub cloud deployment $ wget https://raw.github.com/aeolus-incubator/templates/master/fedora_infra/koji/fedora-17/koji_f17.xml // template describing kojibuild cloud deployment $ wget https://raw.github.com/aeolus-incubator/templates/master/fedora_infra/koji/fedora-17/koji_builder_f17.xml // edit kojihub deployment to contain openstack credentials $ vim koji_f17.xml // startup an instance on openstack w/ kojihub setup togo $ ./mycloud.rb koji_f17.xml // grab public address from output, grab kojibuild ssl credentials from new instance $ scp -i ~/os.key ec2-user@kojihub:/etc/pki/koji/kojiadmin.pem . $ scp -i ~/os.key ec2-user@kojihub:/etc/pki/koji/koji_ca_cert.crt . // edit kojibuild deployment to deploy to ec2 w/ correct koji credentials hub address $ vim koji_builder_f17.xml // startup an instance on ec2 w/ kojibuild communicating w/ the hub $ ./mycloud.rb koji_builder_f17.xml // open up a webbrowser, navigating to http://kojihub/koji to use your Koji instance! Mo, Interesting! You can orchestrate all of these steps across/between multiple systems using ansible: http://ansible.cc - I've been documenting spinning up and provisioning instances on my blog in the last week or so. You might take a look - it should solve the problem of the above needing to be so manual of a process and it requires nothing other than ssh be installed on the machine you're trying to configure/control. The problems we have encountered in the fedora infrastructure with koji builders are: 1. having to bring them up and down while waiting for them to complete build process (koji enable-host/disable host) 2. them having no way to recover a build w/o manual intervention if a builder were to crash or go dead during a build 3. the way the builders connect to the hub to get jobs rather than pushing out from the hub to the builders. Mainly this makes it a pain to deal with 1 and 2 above. 4. For completely arbitrary repositories the tagging process for koji seems pretty cumbersome, especially for transient scratch/chain builds. I've talked about some of these on the buildsys list (build...@lists.fedoraproject.org) If you're interested in discussing this further drop by there. Thanks, -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Deploying fedora infrastructure (koji) across clouds
On Wed, 31 Oct 2012, Mo Morsi wrote: #2: Could there be a way to take a (working) nightly build, build one's package against that nightly in a personal build of some sort, and somehow have a verification process that it built in that personal build before it goes into rawhide, etc? (or even... unit tests, etc.)? Absolutely, repositories and packages can be added on the fly, and we can incorporate any image already pushed to the cloud as well as build new ones for our purposes. Is this a new feature in koji, then? B/c in the past adding repositories has been a major limiting factor in koji. Especially untrusted, remote repositories. I think hybrid technologies is the future, being able to leverage cloud resources in addition to and along side of local ones seemlessly in an open manner will really enable us to do some really cool things. I believe Fedora can make great headway and lead on this front, we just have to find what works for people and do it! :-) Have you been following what the infrastructure team has been doing with our private cloud instances and deployment/provisioning there? some info here if you're interested: https://fedoraproject.org/wiki/Infrastructure_private_cloud -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Tue, 30 Oct 2012, Paul W. Frields wrote: On Tue, Oct 30, 2012 at 11:45:02AM -0700, Adam Williamson wrote: On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote: I don't know if it's impossible to revert to the F17 anaconda at this time, however it is clear that F18 is going to be the longest release cycle we had in 9 years and somehow we need to avoid this in the future. It's not impossible, well, nothing is impossible, but at this point it's almost certainly more of a disruption than just plowing on with newui. Also, I believe we haven't got close to the length of the Fedora Core 5 development cycle, which was more than 9 months.[1] Not that we should aim for it either, but it's certainly not a given we'll even get to that point. Thanks for pointing out that everyone is trying their best to avoid taking that prize. Fedora 5 was 9months intentionally, though. it was intentionally lengthened to see if that would be useful. this time is not intentional, aiui. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, 23 Oct 2012, Lukas Zapletal wrote: Fedora Infrastructure has begun using ansible for some system setup and other orchestration/automation tasks. Our (just beginning) public repos of it are here: http://infrastructure.fedoraproject.org/cgit/ansible.git/ Just out of my curiosity, is Fedora Infra going to replace Puppet with this, or you are planning to use these two technologies in parallel? As we move things into our private cloud instance we need a provisioning system that: 1. doesn't have a bunch of painful dependencies that go on every system (ruby) 2. doesn't require us to provision our systems before we provision our systems 3. doesn't require some other other daemon or cron job running on the systems to maintain them If it can take care of the needs we have I would certainly like to replace puppet. I do not speak for everyone work on the infrastructure team, but I am working on it as if our goal is replacement. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Mon, 22 Oct 2012, Miloslav Trmač wrote: On Sat, Oct 20, 2012 at 1:31 AM, Seth Vidal skvi...@fedoraproject.org wrote: There is a reason I want to move to a clientless configmgmt infrastructure. Could you explain what you mean by clientless, please? It seems to me that there always needs to be something running at the client handling the data from the server, and therefore there needs to be either a protocol or a data format the client and the server have in common. http://ansible.cc It connects via ssh, pushes the code it needs to run over and executes it. You're right that it does require something running on the client: sshd From a software standpoint it assumes you have python installed on the clients, but that's only by default, you could write modules instead in plain shell or in C and it would work just fine. It counts on json for output. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Mon, 22 Oct 2012, john.flor...@dart.biz wrote: ansibile is exactly what I've been looking at as a puppet replacement. If anyone has experience with both, I'd greatly appreciate hearing of their experiences. I don't relish the idea of making the conversion, but I really do get the impression life would be simpler with ansible once there. Or am I just falling for that greener grass on the other side of the fence? Fedora Infrastructure has begun using ansible for some system setup and other orchestration/automation tasks. Our (just beginning) public repos of it are here: http://infrastructure.fedoraproject.org/cgit/ansible.git/ -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, 19 Oct 2012, Michael Stahnke wrote: Puppet in the Fedora/EPEL ecosystem is a bit wonky currently. I'd really like to fix it. Problems: * Fedora 17 (and higher) ships with Ruby 1.9.x and Puppet 2.7.x. 2.7.x is not 100% compatible with 1.9.3. The number of issues in this space continues to grow. * EPEL 5/6 still have Puppet 2.6.x in stable. This version of Puppet isn't maintained any more, other than security fixes. Isn't 'not maintained anymore other than security fixes' Exactly what epel (and rhel for that matter) all about? also - if I have a puppet master on rhel5 and my clients on rhel6 - how well does that work? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, 19 Oct 2012, Michael Stahnke wrote: I (we) completely realize this isn't totally awesome either. This is a problem when you have a distributed application that is trying to support the widest variety of host populations we can. This request was brought to us by community members, Red Hat employees, and business partners as well. I am happy to discuss other soutions/ideas too though. I am not 100% convinced my proposal is the best. I'm less worried about the people requesting the newness b/c they clearly want change. I'm worried about the people who run rhel b/c they fear change. Perhaps they aren't likely to run epel, except it feels like they will run epel. b/c it is pushed so hard by all the el6's. I agree it is a suboptimal solution. Hey, since you work for puppetlabs - I have a new idea - make them maintain backward compat with 2.6 :) That solves the problem for everyone, right? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, 19 Oct 2012, Michael Stahnke wrote: On Fri, Oct 19, 2012 at 4:22 PM, Seth Vidal skvi...@fedoraproject.org wrote: On Fri, 19 Oct 2012, Michael Stahnke wrote: I (we) completely realize this isn't totally awesome either. This is a problem when you have a distributed application that is trying to support the widest variety of host populations we can. This request was brought to us by community members, Red Hat employees, and business partners as well. I am happy to discuss other soutions/ideas too though. I am not 100% convinced my proposal is the best. I'm less worried about the people requesting the newness b/c they clearly want change. I'm worried about the people who run rhel b/c they fear change. I'm more worried about people with hybrid environments where RHEL is at the core for Puppet. (and somewhat how RHEL 7 could shake out) Do you consider it ok to not be able to have Fedora agents check into a RHEL master? There is a reason I want to move to a clientless configmgmt infrastructure. I do not want to be hogtied like this again. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, 19 Oct 2012, Matthew Miller wrote: On Fri, Oct 19, 2012 at 07:31:57PM -0400, Seth Vidal wrote: There is a reason I want to move to a clientless configmgmt infrastructure. I do not want to be hogtied like this again. Yeah, but we're not going to make _you_ use Puppet. :) Damned if some folks don't seem to try. ;) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, 19 Oct 2012, Ken Dreyer wrote: On Fri, Oct 19, 2012 at 5:04 PM, Michael Stahnke stah...@puppetlabs.com wrote: My proposal would be the following: * Move EPEL 6, Fedora = 17 to use Puppet 3.0. * Move EPEL 5 to the latest 2.7.x branch. This is the last branch of Puppet that supports Ruby 1.8.5, and works with 3.0 masters. The last big Puppet move in EPEL (0.25 to 2.6) went well, so I welcome this change. It did? Istr a number of things on our systems going completely sideways. Maybe that was a different transition. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Taking over orphaned Func and Certmaster packages
On Thu, 11 Oct 2012, Steve Salevan wrote: Hey guys, I'd like to put my name in to take over ownership of the orphaned Func and Certmaster packages as per the orphaned package takeover procedure. I am the new project maintainer for these projects, and I'd like to add a few tuneups here and there that we've found useful out here at Tumblr. My Fedora Project username is ssalevan and I've applied for commit and bugzilla watching on each package branch; let me know if I can provide any further information, and I very much appreciate the consideration. I just orphaned the packages and I'm vouching for Steve as the new func maintainer. How should I go about having him take them over? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Feature Suggestion] UsrMove continued
On Wed, 10 Oct 2012, Matěj Cepl wrote: On Wed, 10 Oct 2012 13:11:12 +0300, Serge wrote: Turning /lib into /usr/lib was also incompatible with every other Linux distro, nevertheless it's already done. The fact that we've made one useless and harmful mistake doesn't mean that we should repeat it all the time. I cannot agree enough. Just b/c we've blundered down a bad route doesn't mean you cannot turn back. Instead of chiseling our way back, let's just revert and go. Not every decision a distribution makes is a good one, lets not get caught up believing that we cannot make mistakes. UsrMove was a mistake. End of discussion. Let's go back. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On Wed, 10 Oct 2012, Lennart Poettering wrote: On Tue, 09.10.12 22:30, Simo Sorce (s...@redhat.com) wrote: logrotate has time based policies for very good reasons. Yeah, because Unix doesn't really allow much else... Oh come on, stop bashing unix, logrotate could certainly grow a size checking policy if people felt the need, unix is not holding you back, in fact you are building this stuff on a unix-like system. Ah, Unix cron can start things based on disk space changes? Interesting, I wasn't aware of that. I thought it only could start logrotate by time, not by disk space changes... yum info incron Description : This program is an inotify cron system. : It consists of a daemon and a table manipulator. : You can use it a similar way as the regular cron. : The difference is that the inotify cron handles : filesystem events rather than time periods. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On Wed, 10 Oct 2012, Lennart Poettering wrote: On Wed, 10.10.12 14:16, Seth Vidal (skvi...@fedoraproject.org) wrote: On Tue, 09.10.12 22:30, Simo Sorce (s...@redhat.com) wrote: logrotate has time based policies for very good reasons. Yeah, because Unix doesn't really allow much else... Oh come on, stop bashing unix, logrotate could certainly grow a size checking policy if people felt the need, unix is not holding you back, in fact you are building this stuff on a unix-like system. Ah, Unix cron can start things based on disk space changes? Interesting, I wasn't aware of that. I thought it only could start logrotate by time, not by disk space changes... yum info incron Description : This program is an inotify cron system. : It consists of a daemon and a table manipulator. : You can use it a similar way as the regular cron. : The difference is that the inotify cron handles : filesystem events rather than time periods. And rsyslog pulls that in? I wasn't aware of that. I am learning new stuff every day... I never said anything like that. I said it existed. Please stop adding words where they are not. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On Wed, 10 Oct 2012, Kay Sievers wrote: So, in other words, all our existing log analysis tools have to be modified if they are to be of any use in Fedora 18? What part of Run the syslog daemon like you always did, if you need syslog files. did you not understand? Kay, This is not an acceptable tone. There is no need for this sort of sarcasm or snark. Please amend this in the future. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Tue, 9 Oct 2012, Lennart Poettering wrote: Maybe the definition of the fedora base set needs a bit of updating, given that it considers rdisc, saslauthd, audit, dnsmasq, syslog, wpa supplicant and sendmail basic. For container setups I need nothing of that... (heck! for my non-containerized server I don't need that either...) For minimal installs you also need a tool that can do automatic installation of dependencies. Otherwise the first thing every admin who installs minimal will have to do is to fetch down yum, python, etc to get themselves rolling. Maybe in the eventual future dnf, libzypp etc will be fetched down - but in either case minimal requires such a tool as part of it. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Tue, 9 Oct 2012, Matthew Miller wrote: On Tue, Oct 09, 2012 at 03:18:25PM +0200, Lennart Poettering wrote: To build such an image I'd really would have preferred not installing the docs. It appears rpm once had a feature for that where you could add excludedocs in rpmrc. This feature seems to have been removed. Why? Can we get that back? Or can I enable this for yum in some other way? Anyone has an idea? +1 to this, although note that we currently ship licenses as doc files, and so that might need to go by packaging/legal. There's a yum plugin which sets RPM transaction flags (yum-plugin-tsflags), and with that we could put tsflags=nodocs in the yum.conf. Not sure how to get that up to spin-creation tools, and if we're going to count on it it could probably use some polish and integration. info Yeah that goes along with nodocs. :) --nodocs and tsflags=nodocs ends up with ugly ugly things when you want to do rpm -Va later. nodocs 'works' but not in a pretty way -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Tue, 9 Oct 2012, Lennart Poettering wrote: --nodocs and tsflags=nodocs ends up with ugly ugly things when you want to do rpm -Va later. nodocs 'works' but not in a pretty way But shouldn't we make it possible to make it work in a pretty way? You'll need to get the packaging team on board with it. I have to say it is pretty much non-existent as a priority to anyone I've spoken with. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Tue, 9 Oct 2012, Panu Matilainen wrote: --nodocs and tsflags=nodocs ends up with ugly ugly things when you want to do rpm -Va later. Err, not. Rpm remembers files that were skipped on purpose and does not whine about them on verification: [root@turre ~]# rpm -U --excludedocs /tmp/telnet-0.17-53.fc17.x86_64.rpm [root@turre ~]# rpm -V telnet [root@turre ~]# rpm -ql --state telnet normal/usr/bin/telnet not installed /usr/share/doc/telnet-0.17 not installed /usr/share/doc/telnet-0.17/README not installed /usr/share/man/man1/telnet.1.gz That's good to see. It didn't USED to work that way. I know this b/c when I added tsflags=nodocs I got whined at by people about rpm -Va broke -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Tue, 9 Oct 2012, Matthew Miller wrote: On Tue, Oct 09, 2012 at 10:18:27AM -0400, Seth Vidal wrote: You'll need to get the packaging team on board with it. I have to say it is pretty much non-existent as a priority to anyone I've spoken with. If we can save space in the minimal cloud image, it seems worth doing to me. Looks like in the current EC2 instance, it's about 35M (minus a few K for licenses). 35M? That feels a lot like 'meh' to me. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]
On Tue, 9 Oct 2012, Lennart Poettering wrote: Rotation happens in-line, i.e. each time before we are about to write an entry we check if rotation is necessary and execute it. This should make things a lot more robust, as this fixes a common issue with syslog where a lot of data generated in bursts could flood the fs until a much later time-based rotation took place. This time window goes away with the journal. How can you configure how much log data is kept and for how long? Rotation is strictly bound to disk size and space. There's an upper limit on how much journald will consume, and a lower limit on how much journald will always leave free. This must be changed. Many policies at IT departments world wide have a date-based requirement, not a disk space size. It is simply unacceptable. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd requires HTTP server and serves QR codes
On Tue, 9 Oct 2012, Lennart Poettering wrote: On Tue, 09.10.12 20:20, Panu Matilainen (pmati...@laiskiainen.org) wrote: It's 28M of my 434M F18 container image. i.e. 6.5% of the disk space. /usr/lib/locale and /usr/share/locale are 148M of my 434M container image, i.e. 35%. I wonder if we could do something about that. Is there a way to tell yum not to install any translations, or just translations for a certain set of languages? Yup, another rpm macro configuration item (this is obviously the default): # A colon separated list of desired locales to be installed; # all means install all locale specific files. # %_install_langs all Seth, any chance we can get this exposed on the yum cmdline somehow? I'd really like to use this on the yum command line to install a container with --installroot, and having to edit the host rpmrc for that really sucks... It's not up to me. Talk to the packaging team. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Could not execute scratch_build: database outage
On Tue, 28 Aug 2012, Neal Becker wrote: I assume this is a known (and temporary problem): fedpkg scratch-build Could not execute scratch_build: database outage yep - it is coming back in just a tick -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Suggestion: Continuous mass rebuild
On Mon, 30 Jul 2012, Jesse Keating wrote: On 07/29/2012 10:38 AM, Richard W.M. Jones wrote: Currently we're doing a mass rebuild about every couple of releases, ie. once a year. Since Dennis Gilmore has written this rebuild script already, why don't we run the script more or less continuously? Obviously we could pace the builds so they happen for each package about once a month and don't overload Koji. Then we track packages that don't build, say, 3 times in a row, and file FTBFS bugs for them and after that prioritize fixing them or kick them out of the distro. Rich. Matt Domsch used to do this on the side, which is the right way to do it. If he's not doing it anymore, I would urge some concerned contributor to help setup the infrastructure to do it again. There's been a lot of work to make it so we can do it ourselves. If anyone wants to help out on it I can point you to what we built. Until we get the new hw active we will be limited on where we can run, though. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Suggestion: Continuous mass rebuild
On Sun, 29 Jul 2012, Tom Lane wrote: Richard W.M. Jones rjo...@redhat.com writes: Currently we're doing a mass rebuild about every couple of releases, ie. once a year. Since Dennis Gilmore has written this rebuild script already, why don't we run the script more or less continuously? Obviously we could pace the builds so they happen for each package about once a month and don't overload Koji. Then we track packages that don't build, say, 3 times in a row, and file FTBFS bugs for them and after that prioritize fixing them or kick them out of the distro. I don't think we should do this exactly like a regular mass rebuild: it would create useless churn in the package set, specfile changelogs, etc. What would be useful is to do scratch rebuilds on this sort of schedule, without changing anything in git, and file bugs anytime a rebuild fails. That is more or less what Matt Domsch used to be doing; now that he seems to have stopped, I agree that it would be a good thing for the Fedora project to start doing it officially. And we've been making progress on doing this - however we had to make sure we had sufficient builder systems and a way to quickly redeploy them. That's what I've been working on: https://fedoraproject.org/wiki/User:Skvidal/BuildSystem -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anyone noticed strange signals (segfaults?) delivered to processes in latest Rawhide in Koji?
On Fri, 27 Jul 2012, Richard W.M. Jones wrote: https://bugzilla.redhat.com/show_bug.cgi?id=843731 Always the same process (ocamlopt.opt) and always on 32 bit only. The thing is, it *didn't* happen just 3 days ago. Nothing has changed in the package, and ocamlopt.opt is the same as 3 days ago. glibc has had a few memory-related fixes in the past 3 days: - Revert patch for BZ696143, it made it impossible to use IPV6 addresses explicitly in getaddrinfo, which in turn broke ssh, apache and other code. (#808147) - Avoid another unbound alloca in vfprintf (#841318) - Remove /etc/localtime.tzupdate in lua scriptlets - Revert back to using posix.symlink as posix.link with a 3rd argument isn't supported in the lua version embedded in rpm. - Revert recent changes to res_send (804630, 835090). - Fix memcpy args in res_send (#841787). Has something changed in Koji or mock such as inherited signal masks? I even went as far as building a 32 bit Rawhide VM to test this, but I can't reproduce it there, and that's pretty odd considering it happens reliably in Koji. Do you happen to know how much memory that build consumes? Most of the new builders are 4GB instances(w/ 2GB of swap) - could you be hitting the top end of memory? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
