Re: Support terminate build on files listed twice.
On Mon, 26 Aug 2013, Jeffrey Johnson wrote: See other comments: Resolving simple build flaws rather than detecting and terminating a build configurably is what is needed. Avoiding unexpected breakage and avoiding new support load models is a Good Thing (tm) I would write that: Resolving simple build flaws and emitting a warning, rather than ... just as GCC permits, but does not require, -Werror and -pedantic-error as options That enables the Pedant to engage in self-abuse, without permitting him to become the dictator to require everyone else to follow the pedant's path to salvation or damnation -- Russ herrold __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
refined implementation of set-versions
On Fri, 20 Apr 2012, Alexey Tourbin wrote: I have just learnt that rpm5 project has borrowed set-string implementation recently from ALT Linux. At the very same time, I was working on on a new and improved encoding scheme which can make ... This is exciting news -- This seems like it would be a useful library. What package in ALT are you doing this work in, or alternatiely, is there a version control repository that I could check out to read your ongoing work? Thank you -- Russ herrold __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: building rpm 5.4.1
On Sun, 31 Jul 2011, Jeff Johnson wrote: Java is an atrocity … cvs is just mildly senile … works fine if speak slowly … * chuckle * I've recently been tracking a SVN using project with a daily SVN pull -- SVN seems to have followed in its ancestor's path as to not being a speed daemon - R __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: ordering issues
On Thu, 13 Jan 2011, Matthew Dawkins wrote: The question I have for both Jeff and Per, is flattening initial rpms packages to get these needed pieces in place before and actual chroot install begins and super unacceptable hack? I have no idea what a 'super unacceptable hack' is as a goal goodness metric The goal is to build 'complete' chroots here, for later use either as an install image, or a build environment, right? 1. Make up a MANIFEST of all the packages (ir if binaries, the holding package in tour distribution of choice) that HAVE to be in the final chroot 2. Do some minimal prep of the chroot -- on items we know RPM is doing to look at ./etc/mtab ./etc/fstab ./var/lib/rpm/, a minimally populated ./etc/passwd setup, --bind mounts, etc 3. Copy the rpms (and such dependencies as are revealed in a moment) into a staging area inside the chroot ./var/spool/staging/ or such 4. foreach ELEMENT in MANIFEST, walk a rpm -ivh --root=(chroot) --noscripts (ELEMENT) and identify anything missing, re-order seqecnce to cut noise if it offends, and tweak steps 2 and 3 above 5. When happy, re-run it rpm -Uvh --force --root=(chroot) (ELEMENT) Build environments less picky than install images as to bootloader fixup; extra points for adding SElinux pass at the end of all that As I recall, yum intentionally does not expose some of those options; differing DB environments inside and out side the chroot require a fixup of one want to execure rpm transactions inside the chroot Automate steps 1, 2, 3 and 4 to taste. Eventualy, you'll be satisfied. There is not s single general solution, no 'one ring to rule them all' because one may or may not stub one's toes on a given sub-issue. If that is a 'super unacceptible hack' so be it -- Russ herrold __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
building question as to the DISPLAY variable
Cruising my bugs upstream (I file them, and advance them in front of the Fedorian borg's autocloser to amuse myself, and not with much expectation of resolution) I just got the semi-annual set of proposed auto-closes of neglected bugs, and am re-verifying and advancing them today One is this https://bugzilla.redhat.com/show_bug.cgi?id=498067 Yanko Kaneti 2009-07-14 11:20:46 EDT You can't expect to have DISPLAY in the buildroot. The builders are nominally headless boxes. my reaction to this is: what a crock -- there are virtual, and framebuffer, and lord know how many ways to express what SEEMS to be a X DISPLAY environment inside a build instance (chroot, machine without a running X, whatever) Obviously environments without X at all -- Cocoa, etc, -- must solve this as well What are the team's thoughts to suggest here? -- Russ herrold __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: building question as to the DISPLAY variable
On Thu, 4 Nov 2010, Michael Jennings wrote: On Thursday, 04 November 2010, at 10:13:09 (-0400), Fix the package that erroneously assumes that lack of $DISPLAY implies lack of Tk for build. I did not give enough context -- I did a run of several hundred R ad-on packagings, and several need or want a DISPLAY, to pass ther 'make test' phase equivalent and frankly if I can 'fake' its presence in a reasonable future-proof manner, as a short term and purely tactical expedient, I'll do so [herr...@centos-5 build]$ cd R [herr...@centos-5 R]$ find -name *.src.rpm | wc 374 374 14175 as it lets me clean one some blockers btw -- Hi, Michael ... I was wading through early cAos build design documents I wrote many many moons ago and though of you and Mezz -- Russ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
RPM: rpm-5_3: rpm/macros/ ruby.in
On Sat, 16 Oct 2010, Jeff Johnson wrote: Fixup the Snake eggs too please (i.e. Python eggs aren't building on CentOS 5.5 grr ...) as I recall, I have to add a package not present in the upstream in its 5 series, to solve this python-setuptools-devel-0.6c8-1orc http://orcorc.blogspot.com/2009_10_01_archive.html as I recall, prolly pulled from Raw Hide, but I've had to build so much snake stuff for 5 I rather forget -- six needs to issue, dammit [herr...@centos-5 ~]$ rpm -qa pyth\* | grep orc python-twisted-lore-8.2.0-2orc python-twisted-web-8.2.0-2orc python-setuptools-devel-0.6c8-1orc python-pycurl-7.15.5.1-4orc python-babel-0.9.2-1orc python-exo-0.3.104-1orc python-googlevoice-0.4-2orc python-simplejson-2.0.3-2orc python-twisted-mail-8.2.0-2orc python-nose-0.10.3-1orc python-netaddr-0.5.2-2orc python-decoratortools-1.4-2orc python-twisted-runner-8.2.0-2orc python-crypto-2.0.1-7.1orc python-twisted-words-8.2.0-2orc python-setuptools-0.6c8-1orc python-paste-1.7.2-3orc python-sqlite2-2.3.3-1orc python-bugzilla-0.5.1-2orc python-feedparser-4.1-8orc python-twisted-names-8.2.0-2orc python-twisted-news-8.2.0-2orc python-flup-1.0-2orc python-decorator-3.0.1-2orc python-zope-interface-3.5.2-1orc python-paver-1.0-2orc python-ctypes-1.0.0-1orc python-fpconst-0.7.3-6orc python-twisted-conch-8.2.0-2orc python-smbios-2.2.26-3orc python-pygments-1.0-4orc python-sqlalchemy-0.5.4-1.p2orc python-dictclient-1.0.1-4orc python-twisted-core-doc-8.2.0-2orc python-sphinx-0.6.1-2orc python-docutils-0.5-3orc python-jinja2-2.1.1-2orc python-lxml-2.1.2-1orc python-configobj-4.5.3-4orc python-zope-filesystem-1-3orc python-twitter-0.5-2orc python-paramiko-1.7.3-1orc python-fedora-0.3.13.1-1orc python-enchant-1.1.5-2orc python-twisted-core-8.2.0-2orc python-twisted-8.2.0-2orc python-cherrypy-3.1.2-1orc python-dateutil-1.4.1-3orc [herr...@centos-5 ~]$ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Would patches for Windows be accepted? (No, please go away is OK)
On Sun, 10 Jan 2010, Tor Lillqvist wrote: I have been doing some initial small steps to make RPM work on Windows. (Well, a subset, just package management, definitely not the rpmbuild aspect for instance.) there is a somehwat stale version in Cygwin as well, to which you may also want to look. -- Russ herrold __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
RPM: rpm-5_1: rpm/ CHANGES rpm/lib/ fsm.c librpm.vers rpminstall...
On Mon, 6 Oct 2008, Jeff Johnson wrote: There's also a test for MakeMaker that might be usefully added to AutoFu. OTOH its also perfectly OK to assume that perl implies MakeMaker is installed imho. I am away from the test bench with the correct environment, but don't I recall that the perl in RHEL 3 lacked MakeMaker? Portibility to platforms with older perls may be impaired. -- Russ herrold __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Mandatory/enforcing checks for reproducible builds
On Sun, 28 Sep 2008, Jeff Johnson wrote: There are two big lies with rpm packaging methodolgy. (aside) The other lie is that rpm install transactions are atomic iff there are no packaging flaws or install host failures. But this lie is reproducible builds, which is true wrto rpmbuild iff the build host is set up (including configuration) equivalently/identically. ... I'll work up a proof-of-concept example over the next couple of months ... Opinions? The saying is: If you are not the lead dog, the view never changes. Looking at: https://www.redhat.com/archives/rpm-list/2003-January/msg00136.html I am pretty sure we have been on this Iditarod before. Infinite looping, anyone? ;) -- Russ herrold __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Is there an implementation for PCRE - POSIX interconversion?
On Sat, 19 Apr 2008, Jeff Johnson wrote:
A little reading indicates that I have inadvertently worded
my question re a PCRE - POSIX conversion implementation
incorrectly.
...
I was hoping that the _SYNTAX_ can be interconverted for a
significant subset of all possible PCRE - POSIX
expressions. I'm perfectly willing to try a imperfect, known
flawed, interconversion of _SYNTAX_ if the patterns that are
typically needed by RPM can be mostly converted reliably.
Note: significant and typically needed. YMMV, as always.
I think this article encapsulates the issue I was noting in my
IRC remarks yesterday, mentioning classical Unix, FSF,
procmail !, and other varaints;
http://en.wikipedia.org/wiki/Regular_expression
[ Perl has a more predictable and much richer syntax than the
[ POSIX basic (BRE) and extended (ERE) regular expression
[ standards. ... other utilities ... have adopted syntax
[ similar to Perl's — for example ... PCRE ... [and others not
[ listed each] use regular expression syntax similar to Perl's
That is, there has been a 'pick and choose' over time, and of
course a series of 'improvements' and 'regularizations'
The implied requirement of a quest to find a prebuilt tool to
automatically do all possible inverse transforms, from the
initial use of the bare '-', was probably doomed to 'no
reply' -- The article notes that there is an incompatible
even in the standard for simplest variation of POSIX 'basic'
and 'extended' forms:
[ The meaning of metacharacters escaped with a backslash is
[ reversed for some characters in the POSIX Extended Regular
[ Expression (ERE) syntax
so absent an option switch, no 'perfect' inverset (',-.') set
of transform can exist. Move a few generations away into PRCE
and ...
-- Russ herrold
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Is there an implementation for PCRE - POSIX interconversion?
On Sat, 19 Apr 2008, R P Herrold wrote: wtf ??? These two block qoutes got recormatted by alpine 1.10, or the ML software ... gr [ Perl has a more predictable and much richer syntax than the [ POSIX basic (BRE) and extended (ERE) regular expression [ standards. ... other utilities ... have adopted syntax [ similar to Perl's — for example ... PCRE ... [and others not [ listed each] use regular expression syntax similar to Perl's [ The meaning of metacharacters escaped with a backslash is [ reversed for some characters in the POSIX Extended Regular [ Expression (ERE) syntax -- R __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
RE: Is there an implementation for PCRE - POSIX interconversion?
On Fri, 18 Apr 2008, Wichmann, Mats D wrote: Hey speaking of wars, let's provide another excuse to put PCRE into LSB :-) (I've already been thinking about that, FWIW) Bad Mats; bad bad Mats :-) -- Russ herrold __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm-5.0.Z releases and rpm-5.1 ROADMAP
On Tue, 5 Feb 2008, Jason Corley wrote: - integrated depsolver The issue there, as I see it, is what (existing, additional, new ?) mechanisms will be devised to specify 'target repositories' to consider in doing the dep-solveing. A whole set of structures in the yum space have emerged, to specify candidate repositories to use (along with some lily gilding about excludes, and priorities.) Also the format has been tweaked with some changes occasionally. No reason not to accept the hint (pointer) to the top of archives, as per 'createrepo' as that has become familiar, but should one suck in the metadata, or pull it off the observed binary RPM's found? Debian solved it another way -- should RPM 'grok' /etc/apt/sources.list as well? What other archive identification mechanisms are out there which need to be considered which I have missed? BSD ports pointers? HP Depot pointers ;) ? -- Russ herrold __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: vcheck(1), was: Re: RPM 5 status quo
On Mon, 23 Jul 2007, Ralf S. Engelschall wrote: which in turn points to a dead link. Is there a new reference archive? Yes, vcheck(1) some times ago disappeared on the net. ftp://ftp.openpkg.org/sources/DST/vcheck/ thank you. -- Russ Herrold __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: testing RPM 5 in practice: Berkeley-DB to SQLite migration with --rebuilddb
On Sun, 22 Jul 2007, Ralf S. Engelschall wrote: Well, as I already said twice on rpm-devel@, I would like to use SQLite in OpenPKG -- at least as a fully functional alternative to Berkeley-DB, i.e., until we officially decided to use SQLite only, I want to use BDB still by default (for stepping up from RPM 4 to RPM 5) and let us switch Ralf I just just do not understand this infatuation with SQLite, but when carried in parallel to BDB, or rolling in a filesystem flatfile store, it is perhaps harmless to fall in love with an idea. But, I guess I do not understand this: until we officially decided to use SQLite only 'we' MUST mean some OpenPKG decision, because it clearly does not reflect a decision for the database direction that mainline RPM5 development has in any way 'officially decided'. Jeff has made it completely clear that pushing in different database backends has been tried, but that he has not seen a sufficient use case for HIM to be interested in chasing what is clearly to him, a poor and pointless change. Why badger him to discuss things which he clearly has little interest beyond historical knowledge, and no developmental interest in? The BDB model, and the SQL model are not a one to one mapping in API; it is a forced fit at best to graft SQLite syntax onto a tool with BDB in its roots. Some kind of perl-DBI like abstraction _may_ be possible, but the overhead for adding the database abstraction hooks will _gain_ nothing from Jeff's clearly stated point of view; rather it will add points of failure, and cost in maintenance. How is this a win here? -- Russ Herrold __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
vcheck(1), was: Re: RPM 5 status quo
On Sat, 21 Jul 2007, Ralf S. Engelschall wrote: Sorry, the particular web user interface currently is not available in public or even as Open Source. Only the underlying vcheck(1) program and the over 1000 %track sections we developed using this tool are available as Open Source. Google looking in the openpkg archive finds this: http://www.openpkg.org/product/packages/?package=vcheck which in turn points to a dead link. Is there a new reference archive? -- Russ Herrold __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
