Re: libexec and multi-arch

> On Feb 5, 2018, at 5:46 PM, Tomasz Pala <go...@polanet.pl> wrote: > > On Mon, Feb 05, 2018 at 15:20:55 -0500, Jeff Johnson wrote: > >>> No, it only hidden the problem behind getconf binary being handled >>> _somehow_. I once even wondered how this i

Re: libexec and multi-arch

> On Feb 5, 2018, at 3:23 PM, Neal Gompa wrote: > > I'd probably argue that libexec should have the same multi-arch > handling that (s)bin does (primary arch "wins" and secondary arches > are ignored), though last I checked this isn't specific to paths and > should Just

Re: libexec and multi-arch

> On Feb 5, 2018, at 10:13 AM, Tomasz Pala wrote: > >> On Mon, Feb 05, 2018 at 10:47:32 +0100, Jacek Konieczny wrote: >> >> Using lib/lib64/libx32 instead of libexec was much smarter in this case. > > No, it only hidden the problem behind getconf binary being handled >

RPM+MQTT in rpm-5.4.18 ...

rpm-5.4.18 (soon) will embed the paho-mqtt client to do MQTT messaging. I will likely do a snapshot of 5.4.18 as soon as I haul out some MQTT debugging trash and repair portability damage. TL;DR Don't install paho-mqtt-1.1.0 and/or build rpm-5.4.18 --without-mqtt and ignore the rest of

Re: python packaging

On Jun 20, 2016, at 10:11 AM, Jacek Konieczny wrote: > >> reality is that we have no consistency, > > Some people seem to don't care at all. :-( > I am afraid, that whatever scheme we decide on, people will still commit > crap. That is minority, but quite annoying. > Distro package naming

Re: rpm -Uhv --oldpackage loses configs

On Jun 7, 2016, at 10:45 AM, Elan Ruusamäe wrote: > On 07.06.2016 17:39, Jeff Johnson wrote: >> Were the files present on the file system (presumably not, but I'd like >> confirmation)? > yes of course they were present. otherwise there would not be messages from > rpm lik

Re: rpm -Uhv --oldpackage loses configs

On Jun 7, 2016, at 10:44 AM, Elan Ruusamäe wrote: > >> Do the repackaged rpm’s contain those files.? > > the config files are present in .rpm file and in rpmdb where i installed the > .rpm file: > > # rpm -qplvc 1465233457/pam-1.1.8-8.x86_64.rpm|grep auth > -rw-r--r--1 rootroot

Re: rpm -Uhv --oldpackage loses configs

On Jun 7, 2016, at 10:37 AM, Elan Ruusamäe wrote: > On 07.06.2016 17:31, Jeffrey Johnson wrote: >> Its still not clear to me whether the new package files were installed or >> not. > they were not > > mv -i will ask to overwrite files, it never asked ... so... > Yes I read the man page.

rpm needs db-6.1.26+ patch (was Re: python3 optional deps)

On Jun 1, 2016, at 6:29 PM, Elan Ruusamäe wrote: > > 1. were in middle of 5.4.15 -> 5.4.17 change The attached patch (for db-6.1.26/db-6.2.23) is necessary with rpm-5.4.x). Earlier versions of db-x.y.z need no modification. hth 73 de Jeff == jbj13.patch

Re: ldconfig forgotten

On May 31, 2016, at 6:30 PM, Elan Ruusamäe wrote: > On 01.06.2016 00:47, Jeff Johnson wrote: >> Verified ... how? > in first post i said it's 100% reproducible, > so, > > i applied your patch to rpm, > rebuilt rpm, installed > > and retried the 100% repro

Re: ldconfig forgotten

On May 31, 2016, at 4:47 PM, Elan Ruusamäe wrote: > On 31.05.2016 23:37, Jeff Johnson wrote: >> On May 31, 2016, at 4:33 PM, Elan Ruusamäe wrote: >>> i prefer reliability over broken optimization. >>> >> So disable the optimization. I'm quite sure I

Re: ldconfig forgotten

On May 31, 2016, at 4:33 PM, Elan Ruusamäe wrote: > > i prefer reliability over broken optimization. > So disable the optimization. I'm quite sure I have described how to disable the optimization on this (and other) mailing lists in the past 10 years. 73 de Jeff

Re: ldconfig forgotten

On May 31, 2016, at 2:52 AM, Elan Ruusamäe wrote: > On 31.05.2016 09:45, Elan Ruusamäe wrote: >> [root@57c8cccdc671 bin]# poldek -u procps > oh, and it's 100% reproducible: > Yes. And it has been discussed many times over the last 15y, several times on this list. Short answer:

Re: man-pages-4.05-1.noarch conflicts with lirc-0.9.3a-1.x86_64

On May 10, 2016, at 6:30 AM, Elan Ruusamäe wrote: > On 10.05.2016 09:12, Jeffrey Johnson wrote: >>> Fixed in lirc-0.9.3a-2 / man-pages-4.05-2. >>> > >> Is file conflict detection an RPM misfeature? > no. it's packaging mistake (two packages installing same file path) > Of course it is a

Re: python3 optional deps

On May 6, 2016, at 3:41 AM, Elan Ruusamäe wrote: > On 06.05.2016 10:11, Jacek Konieczny wrote: >> >> I guess the python dependency generator should be fixed in our RPM, to >> ignore the 'extras' dependencies (or to make them 'suggest', skipping the >> ':python_version' ones. > is there python

Re: how rpm destroyed my private key

On Apr 28, 2016, at 4:43 AM, Elan Ruusamäe wrote: > On 27.04.2016 21:09, Jeff Johnson wrote: >> What I am suggesting is using --justdb --noscripts --notriggers on the v2 >> package before attempting an upgrade. > > you're solving the problem in wrong order. sugge

Re: how rpm destroyed my private key

On Apr 28, 2016, at 4:41 AM, Elan Ruusamäe wrote: > > but rpm i use to manage configuration and expect %noreplace to mean "do not > replace the file". that one technical detail makes it behave differently on > high level does not change my expectation. i'd rather consider it flaw in >

Re: how rpm destroyed my private key

On Apr 27, 2016, at 1:08 PM, Jeff Johnson wrote: > > So why are you claiming RPM "destroyed" your secret_key.php file when you are > misusing > %config(noreplace) > with expectations of behavior that have never been implemented, and cannot be

Re: how rpm destroyed my private key

On Apr 27, 2016, at 10:12 AM, Elan Ruusamäe wrote: > On 27.04.2016 16:55, Jeff Johnson wrote: >> On Apr 27, 2016, at 3:13 AM, Elan Ruusamäe wrote: >> >>> and it did it again! >>> >> You are smart enough to identify a better solution for your problems than

Re: how rpm destroyed my private key

On Apr 27, 2016, at 3:13 AM, Elan Ruusamäe wrote: > and it did it again! > You are smart enough to identify a better solution for your problems than blaming RPM for destroying your files ... again ... and again. 73 de Jeff ___ pld-devel-en mailing

Re: rpm-5.4.16-0.20160321.src.rpm, take 3

On Apr 24, 2016, at 3:29 PM, Elan Ruusamäe wrote: > On 24.04.2016 22:23, Jeff Johnson wrote: >> When was the last time a distro rebuilt a package to correct a spelling >> error typo in, say, >> the Swahili translation? > > fedora rebuilds *all* packages for ea

Re: rpm-5.4.16 snapshot

On Apr 24, 2016, at 3:20 PM, Elan Ruusamäe wrote: > On 24.04.2016 21:08, Jeff Johnson wrote: >> The fix is --without-sasl2 (not --without-sasl). My brain fart, now verified. > > thanks. indeed that's the option. > > seems libacl is also new library dependency.

Re: rpm-5.4.16-0.20160321.src.rpm, take 3

On Apr 24, 2016, at 10:25 AM, Jeff Johnson wrote: ... > > I think that I18N could (and should) be done better in RPM. Meanwhile > devising a transparent > "legacy compatible" retrofit for RPM_I18NSTRING_TYPE is/was the necessary > first step to attempting > a

Re: rpm-5.4.16 snapshot

On Apr 24, 2016, at 12:49 PM, Jeff Johnson wrote: > > On Apr 24, 2016, at 12:32 PM, Elan Ruusamäe wrote: > >> On 24.04.2016 18:28, Jeff Johnson wrote: >>> So specifiying --without-sasl when building is the only (well you could >>> configure/install sasl >&

Re: rpm-5.4.16 snapshot

On Apr 24, 2016, at 12:49 PM, Jeff Johnson wrote: > > (aside) > BTW, there is one other 1-line patch to rpmio/pkgio.c needed to plug a 16b > memory leak > in rdSignature(). The final code should look like > > ... >/* All packages should have RPMSIGTAG_M

Re: rpm-5.4.16 snapshot

On Apr 24, 2016, at 12:32 PM, Elan Ruusamäe wrote: > On 24.04.2016 18:28, Jeff Johnson wrote: >> So specifiying --without-sasl when building is the only (well you could >> configure/install sasl >> correctly before executing rpm too) way to remove the syslog'd message. >

Re: rpm-5.4.16 snapshot

On Apr 24, 2016, at 10:41 AM, Jeff Johnson wrote: >> >> something logs to syslog at this time: >> Apr 24 12:48:27 new-server rpm: looking for plugins in '/usr/lib/sasl2', >> failed to open directory, error: No such file or directory >> > > That

Re: rpm-5.4.16 snapshot

On Apr 24, 2016, at 6:03 AM, Elan Ruusamäe wrote: > On 24.04.2016 12:51, Elan Ruusamäe wrote: >> >> anyway, i finally installed the built version. the sasl2 error is probably >> from somewhere else. >> >> 12:48:25 root[load: 0.00]@new-server /# rpm -q rpm >> rpm-5.4.16-0.1.i686 > There are 1

Fwd: rpm-5.4.16 snapshot

nglish)" <pld-devel-en@lists.pld-linux.org> > > On 20.04.2016 15:38, Jeff Johnson wrote: >> There is a final snapshot release of rpm-5.4.16 now available at >> >> http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT/rpm-5.4.16-0.20160420.src.rpm > > baggins,

Re: rpm-5.4.16-0.20160321.src.rpm, take 3

On Apr 24, 2016, at 6:29 AM, Jan Rękorajski wrote: > On Mon, 21 Mar 2016, Jeff Johnson wrote: > >> There is a 3rd snapshot release of rpm-5.4.16 now available at >> >> >> http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT//rpm-5.4.16-0.20160321.src.rpm >> &g

Re: rpm-5.4.16 snapshot

On Apr 20, 2016, at 11:05 AM, Elan Ruusamäe wrote: > On 20.04.2016 18:01, Elan Ruusamäe wrote: >> On 20.04.2016 15:38, Jeff Johnson wrote: >>> There is a final snapshot release of rpm-5.4.16 now available at >>> >>>http://rpm5.org/files/rpm/rpm-5.4/SN

Re: rpm-5.4.16 snapshot

to enable link time optimization (-flto) and run-time checking (-fsanitize=address et al) have been added. 73 de Jeff On Mar 15, 2016, at 4:50 PM, Jeff Johnson wrote: > There is a snapshot release of rpm-5.4.16 now available at > > > http://rpm5.org/files/rpm/rpm-5.4/

Re: rpm loses %configs

On Apr 19, 2016, at 4:59 PM, Elan Ruusamäe wrote: > i'm pretty sure this has happened before, just did not payed attention > I believe you. Meanwhile ... > so, if i use --nodeps rpm forgets it has to put .rpmnew? > and instead no config files left on the original path (mv -i would had said >

Re: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1

On Apr 18, 2016, at 4:52 AM, Elan Ruusamäe wrote: > > pld rpm links with system libmagic, not using bundled version. i think this > is something broken on library level. > Perhaps the libmagic code is broken, yes. Usually the issue is new definitions, which are increasingly using *RE

Re: [packages/file] - this version breaks rpmbuild, good testcase is gnome-initial-setup package - rel 1.1

On Apr 17, 2016, at 9:44 AM, Jan Rękorajski wrote: > I removed it from ftp and downgraded on builders, building > gnome-initial-setup or jbig2dec causes rpm to hang indefinitely on > "processing files" step. > The coupling between rpmbuild <-> file is through /etc/magic rules (whatever path is

Re: rpm-5.4.16-0.20160321.src.rpm, take 3

On Mar 23, 2016, at 5:37 PM, Elan Ruusamäe wrote: > On 22.03.2016 01:44, Jeff Johnson wrote: >> There is a 3rd snapshot release of rpm-5.4.16 now available at >> >> >> http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT//rpm-5.4.16-0.20160321.src.rpm > > it co

rpm-5.4.16-0.20160321.src.rpm, take 3

There is a 3rd snapshot release of rpm-5.4.16 now available at http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT//rpm-5.4.16-0.20160321.src.rpm This addresses the following issues: 1) mongoc.h needed #include to rebuild with PLD configuration 2) build with or without in "system.h"

Re: rpm-5.4.16 snapshot, take 2

PORT_I18NSTRING_TYPE next. hth 73 de Jeff On Mar 18, 2016, at 3:49 AM, Jeff Johnson wrote: > I have uploaded another snapshot release that addresses > all the issues you have reported: > > rpm-5.4.16-0.20160318.src.rpm > > The issue of garbled text is both locale and

Re: rpm-5.4.16 snapshot

On Mar 16, 2016, at 12:46 PM, Elan Ruusamäe wrote: > On 16.03.2016 18:28, Jeff Johnson wrote: >> There is a recent API change in libtomcrypt (like last few months) > > ah, tomcrypt, > > i think will switch to previous method in pld for now for maximum > compatib

Re: rpm-5.4.16 snapshot

On Mar 16, 2016, at 12:12 PM, Elan Ruusamäe wrote: > On 15.03.2016 22:27, Jeff Johnson wrote: >> There is a snapshot release of rpm-5.4.16 now available at >> >> >> http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT/rpm-5.4.16-0.20160315.src.rpm > >

Re: rpm-5.4.16 snapshot

On Mar 16, 2016, at 1:09 PM, Elan Ruusamäe wrote: > On 15.03.2016 22:27, Jeff Johnson wrote: >> 3) (recommended) rpm-5.4.16 uses db-6.1.23 (not 6.1.26) with >> DB_MULTIVERSION and DB_TXN_SNAPSHOT. >> DB_TXN_SNAPSHOT avoids deadlocks with copy

Re: rpm-5.4.16 snapshot, take 2

I will add shortly. hth 73 de Jeff On Mar 15, 2016, at 6:14 PM, Elan Ruusamäe wrote: > On 15.03.2016 22:27, Jeff Johnson wrote: >> There is a snapshot release of rpm-5.4.16 now available at >> >> >> http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT/rpm-5.4.16-0.2

Re: rpm-5.4.16 snapshot

On Mar 16, 2016, at 3:20 PM, Elan Ruusamäe wrote: > On 15.03.2016 22:27, Jeff Johnson wrote: >> There is a snapshot release of rpm-5.4.16 now available at >> >> >> http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT/rpm-5.4.16-0.20160315.src.rpm > > some rpmi

rpm-5.4.16 snapshot

There is a snapshot release of rpm-5.4.16 now available at http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT/rpm-5.4.16-0.20160315.src.rpm This is the first SRPM built by itself that is headed for release in the next few weeks that is being provided as a public reference point for integration

Re: popt warning

On Feb 23, 2016, at 2:21 PM, Elan Ruusamäe wrote: > > i first noticed it in a code that was invoked from in bash prompt: > > rpm --define "_specdir $PWD" --specfile $specfile -q --qf '%{VERSION}\n' | > head -n1 > > but later i noticed rpm/rpmbuild (invoked from pld builder script) the same

Re: popt warning

On Feb 22, 2016, at 5:23 PM, Elan Ruusamäe wrote: > sometimes i see such message when building packages: > > warning: existing POPT configuration file > "/usr/lib/rpm/rpmpopt:/usr/lib/rpm/%{_target}/rpmpopt:/etc/rpm/rpmpopt.*:/etc/rpm/rpm > popt:/etc/rpm/%{_target}/rpmpopt:~/.rpmpopt"

Re: packages: etckeeper/etckeeper.spec - Up to 0.56

On Aug 24, 2011, at 8:26 AM, Pawel Golaszewski wrote: Maybe each file in filesystem? :P That won't work: one needs to put every byte in a virtualized environment with full hardware enforced isolation to please everyone. And RPM will *still* have extraordinary abilities to be able to

Re: *.py packaging, again

On Jul 14, 2011, at 3:44 AM, Jacek Konieczny wrote: Ok, you may be right. But what than? We don't even have an idea how should the proper rpm solution work and no volunteers to design and code it. At the same time Python 3.2 is waiting for being included in PLD, Um, that isn't true: I did

Re: *.py packaging, again

On Jul 14, 2011, at 4:35 AM, Patryk Zawadzki wrote: In case some automated mechanism is provided, in the future, for keeping the compiled python code files in the RPM database without listing them in the spec files, we loose nothing by having the files there already (by explicitly listing

Re: *.py packaging, again

On Jul 14, 2011, at 7:17 AM, Tomasz Pala wrote: On Thu, Jul 14, 2011 at 10:35:17 +0200, Patryk Zawadzki wrote: compiles stuff? If so, can we then launch a suid helper that injects the newly created files into the rpm package that contained the original .py? OMG... Please don't mess

Re: *.py packaging, again

On Jul 14, 2011, at 8:04 AM, Tomasz Pala wrote: On Thu, Jul 14, 2011 at 07:21:35 -0400, Jeff Johnson wrote: compiles stuff? If so, can we then launch a suid helper that injects the newly created files into the rpm package that contained the original .py? OMG... Please don't mess

Re: *.py packaging, again

On Jul 14, 2011, at 8:05 AM, Tomasz Pala wrote: On Thu, Jul 14, 2011 at 07:19:34 -0400, Jeff Johnson wrote: You also need to decide whether all compilations are on the build system or after installation: there are different implementations. I'd suggest that the problem needs

Re: *.py packaging, again

On Jul 14, 2011, at 9:23 AM, Tomasz Pala wrote: On Thu, Jul 14, 2011 at 08:57:40 -0400, Jeff Johnson wrote: (aside) Do you actually use repackaged packages? For what purpose? Unfortunately yes, for restoring working set - too often... And during tests of course (various, like my private

Re: *.py packaging, again

On Jul 14, 2011, at 11:10 AM, Tomasz Pala wrote: On Thu, Jul 14, 2011 at 17:04:02 +0200, Tomasz Pala wrote: * I had an idea once upon a time to verify content of repackaged files against original digest, I really miss this feature in rpm (rpm -Vp verifies package against filesystem not

Re: *.py packaging, again

On Jul 14, 2011, at 2:31 PM, Artur Wroblewski wrote: On Thu, Jul 14, 2011 at 8:44 AM, Jacek Konieczny jaj...@jajcus.net wrote: [...] We lose: - a little bit of the disk space - some 'purity' some people see in not distributing 'sources' IMHO, it was not about purity but quite practical

Re: *.py packaging, again

On Jul 14, 2011, at 3:52 PM, Artur Wroblewski wrote: On Thu, Jul 14, 2011 at 8:26 PM, Jeff Johnson n3...@mac.com wrote: On Jul 14, 2011, at 2:31 PM, Artur Wroblewski wrote: On Thu, Jul 14, 2011 at 8:44 AM, Jacek Konieczny jaj...@jajcus.net wrote: [...] We lose: - a little bit

Re: *.py packaging, again

On Jul 13, 2011, at 9:07 AM, Jakub Bogusz wrote: I don't like the idea of __pycache__ not managed by rpm (or not We likely disagree on the details, perhaps sharply, of __pycache__ managed by rpm but not on the general goal. maintained with rpm database in case of more robust post

Re: Deps in TH

On Jun 4, 2011, at 9:41 AM, Elan Ruusamäe wrote: On Fri, 03 Jun 2011 12:17:20 -0400, Jeff Johnson wrote: On Jun 3, 2011, at 11:55 AM, Arkadiusz Miskiewicz wrote: We don't have such thing. Feel free to implement (cvs/pld-ftp-admin) but note that in needs to be fast (and speed is the major

Re: Deps in TH

On Jun 3, 2011, at 11:55 AM, Arkadiusz Miskiewicz wrote: We don't have such thing. Feel free to implement (cvs/pld-ftp-admin) but note that in needs to be fast (and speed is the major problem). Its rather easy to do rpm -ivh --dbpath /somewhere/rpmdb --justdb --nonothing *.rpm and

Re: *.la files in xorg* packages

On May 30, 2011, at 1:45 PM, Arkadiusz Miskiewicz wrote: On Monday 30 of May 2011, Tomasz Pala wrote: While updating my system I've noticed that xorg* packages still got *.la files, while they all got *.pc as well. Are there any other (not discussed before) reasons not to remove them?

Re: *.la files in xorg* packages

On May 30, 2011, at 2:05 PM, Arkadiusz Miskiewicz wrote: On Monday 30 of May 2011, Jeff Johnson wrote: On May 30, 2011, at 1:45 PM, Arkadiusz Miskiewicz wrote: On Monday 30 of May 2011, Tomasz Pala wrote: While updating my system I've noticed that xorg* packages still got *.la files, while

Re: python3.2+ compiled files

On Apr 9, 2011, at 2:13 PM, Patryk Zawadzki wrote: 2011/4/9 Elan Ruusamäe g...@pld-linux.org: so my vote goes for keeping the old .py[co] method, and perhaps change to make is package only .pyc, it is rather ratre somebody invokes python with -O option so the .pyo is to be needed. or why it

Re: python3.2+ compiled files

On Apr 9, 2011, at 3:29 PM, Tomasz Pala wrote: On Sat, Apr 09, 2011 at 15:26:46 -0400, Jeff Johnson wrote: There's no known reason why xattr's can't be done in other ways. Like what? Like not having RPM attach xattr's. 5+ years ago, I had to swipe a hunk of code from libselinux and get

Re: python3.2+ compiled files

On Apr 9, 2011, at 3:50 PM, Tomasz Pala wrote: On Sat, Apr 09, 2011 at 15:34:55 -0400, Jeff Johnson wrote: There's no known reason why xattr's can't be done in other ways. Like what? Like not having RPM attach xattr's. Please tell me how to do root-free (capabilities-based) system

Re: python3.2+ compiled files

On Apr 9, 2011, at 4:52 PM, Tomasz Pala wrote: On Sat, Apr 09, 2011 at 16:32:01 -0400, Jeff Johnson wrote: And I've shown that this way is wrong - having xattrs outside package manager is bad design per se. You WILL have users using python eggs, and there WILL be a window installing

Re: python3.2+ compiled files

On Apr 9, 2011, at 6:49 PM, Tomasz Pala wrote: On Sat, Apr 09, 2011 at 17:09:54 -0400, Jeff Johnson wrote: And I'm not disagreeing. How rpm should handle xattr's like that capabilities you want is a whole different matter. Attaching Yet Another per-file tag everywhere just to set

Re: python3.2+ compiled files

On Apr 9, 2011, at 7:38 PM, Tomasz Pala wrote: On Sat, Apr 09, 2011 at 19:05:33 -0400, Jeff Johnson wrote: FOr a distro containing 1M files, empty string tags require (at least) '\0'. But ~1Mb (for a 1M file distro) additional info is moderately significant. Go look at ls -al /var

Re: RPM vs xattrs [was: python3.2+ compiled files]

On Apr 9, 2011, at 8:36 PM, Tomasz Pala wrote: BTW it's you who wrote we've got good engineering practices often. Let's just leave it here: PLD is my favorite distro, solves problems (like *.pyo files changing in python 3.2+), devises fixes, and moves on months and

Re: python3.2+ compiled files

On Apr 3, 2011, at 8:38 AM, Patryk Zawadzki wrote: and sources are often the only source of (up to date) documentation. So the source code is the documentation. What else is new? Are you simply trolling, or just are too ignorant to be aware that's also what happens with all other

Re: python3.2+ compiled files

On Apr 3, 2011, at 9:00 AM, an...@green.mif.pg.gda.pl wrote: Jeff Johnson wrote: Another approach would be to not bother with static *.py* content packaged in *.rpm at all, but rather let python establish its own format/implementation for install/upgrade/erase of python code

Re: python3.2+ compiled files

On Apr 3, 2011, at 9:15 AM, Patryk Zawadzki wrote: On Sun, Apr 3, 2011 at 3:04 PM, Jacek Konieczny jaj...@jajcus.net wrote: On Sun, Apr 03, 2011 at 02:38:49PM +0200, Patryk Zawadzki wrote: Except in Python you can execute/import .py files just fine. If the program is not closed source,

Re: python3.2+ compiled files

On Apr 3, 2011, at 4:01 PM, Patryk Zawadzki wrote: On Sun, Apr 3, 2011 at 3:27 PM, Jeff Johnson n3...@mac.com wrote: I see a problem with /usr/bin/__pycache__/* and the rest of the python litter on a file system. While __pycache__ subdirs works in python's module trees

Re: packages: dovecot/dovecot.spec - TODO was accidentally removed (sorry), but...

On Oct 30, 2010, at 8:08 PM, Paweł Zuzelski wrote: On Thu, 28 Oct 2010, caleb wrote: Author: calebDate: Thu Oct 28 09:53:02 2010 GMT Module: packages Tag: HEAD Log message: - TODO was accidentally removed (sorry), but having

Re: rpm.groups - Libraries/Ruby

On Jun 24, 2010, at 7:31 AM, Bartosz Taudul wrote: 2010/6/24 Paweł Zuzelski z...@xatka.net: Any comments? Why do we care about RPM groups? What else would we discuss if RPMTAG_GROUP did not exist? Did Poland do well in South Africa? 73 de Jeff

Re: rpm.groups - Libraries/Ruby

On Jun 24, 2010, at 9:36 AM, Paweł Zuzelski wrote: On Thu, 24 Jun 2010, Jeff Johnson wrote: What else would we discuss if RPMTAG_GROUP did not exist? Sorry, I don't get it. Translation from obscure jbj-speak: RPMTAG_GROUP is utterly broken as a package metadata item

Re: rpm.groups - Libraries/Ruby

On Jun 24, 2010, at 9:42 AM, Bartosz Taudul wrote: 2010/6/24 Jeff Johnson n3...@mac.com: Why do we care about RPM groups? What else would we discuss if RPMTAG_GROUP did not exist? I was referring to the general shit state of the group hierarchy in PLD. Basically 90% of the stuff

Re: rpm.groups - Libraries/Ruby

On Jun 24, 2010, at 10:11 AM, Artur Wroblewski wrote: 2010/6/24 Jeff Johnson n3...@mac.com: On Jun 24, 2010, at 9:36 AM, Paweł Zuzelski wrote: On Thu, 24 Jun 2010, Jeff Johnson wrote: [...] Did Poland do well in South Africa? Not so bad, we have not lost any game yet. Lots

Re: rpm.groups - Libraries/Ruby

On Jun 24, 2010, at 9:42 AM, Bartosz Taudul wrote: 2010/6/24 Jeff Johnson n3...@mac.com: Why do we care about RPM groups? What else would we discuss if RPMTAG_GROUP did not exist? I was referring to the general shit state of the group hierarchy in PLD. Basically 90% of the stuff

Re: rpm.groups - Libraries/Ruby

On Jun 24, 2010, at 11:22 AM, Bartosz Taudul wrote: New group hierarchy proposition can be found at http://cvs.pld-linux.org/cgi-bin/cvsweb/PLD-doc/nowe-grupy?rev=HEAD. This tree is as good as any other I've seen, certainly far far better than synaptic/aptitude choices. It was based on

Re: poldek -r broken again?

On May 2, 2010, at 3:14 PM, Przemyslaw Iskra wrote: On Sun, May 02, 2010 at 02:57:39PM -0400, Jeff Johnson wrote: chroot(.) = 0 -- chroots back to /tmp ! This way /tmp becomes new root. ... which re-establishes the cwd before embedded lua was run

Re: rpm: POSIX capabilities/ACLs?

On Feb 6, 2010, at 11:56 AM, Tomasz Pala wrote: On Sat, Feb 06, 2010 at 12:04:07 +0100, Zbyniu Krzystolik wrote: Anyone knows if it is or is going to be possible in rpm to store xattrs? Not possible now. And how about The Other RPM? This is a must-be feature and sooner or later we

Re: RFC: Convert bconds to autoconf-like options.

Before you get into a litter of additional macros for bconds, please note that when originally implemented (by PLD, always first ;-) bcond's were intended as booleans. When bconds were picked up by RPM using --with/--without popt aliases (that are essentially just --define wrappings to

Re: RFC: Convert bconds to autoconf-like options.

On Nov 18, 2009, at 11:49 AM, Przemyslaw Iskra wrote: I only really care about %__enable_disable macro which replaces such obscure PLD idiom: --%{?with_runtime:en}%{!?with_runtime:dis}able-runtime-cpudetection with much more readable: %{__enable_disable runtime

Re: configure --host/build/target

On Oct 11, 2009, at 8:01 AM, Arkadiusz Miskiewicz wrote: Does anyone remember why we use such configure macro: ./configure \ --host=%{_target_platform} \ --build=%{_target_platform} \ instead of ./configure \ --host=%{_host_platform} \ --build=%{_build_platform} \

Re: verify rpm package contents

On May 13, 2009, at 1:41 PM, Tomasz Pala wrote: How to verify digest of files in rpm package (like when repackaged modified files)? For example I've got: ~: rpm -qplv xorg-proto-xproto-devel-7.0.14-1.i586.rpm -rw-r--r--1 rootroot 167477 Oct 28 2008 /usr/

Re: topdir macro

On May 3, 2009, at 6:26 AM, Elan Ruusamäe wrote: why not have such default macros: %_topdir%{expand:%%global _topdir %(d=$([ -d ../../ packages ] (cd ../.. pwd)); d=${d:-$([ -d ../packages ] (cd ..; pwd))}; echo ${d:-$HOME/rpm})}%_topdir %_specdir

Re: INFO: cvs downtime

On May 2, 2009, at 5:25 AM, Elan Ruusamäe wrote: I don't want any sources to be fetched. those are patches not sources indeed --fetch-only-spec option would be nice Likely achievable with L and R macro overrides, and a popt alias to hide the --define. (3+ years since fetch being

Re: Merging PLD patches for RPM @rpm5.org

On Jan 18, 2009, at 10:56 AM, Radoslaw Zielinski wrote: Jeff Johnson n3...@mac.com [18-01-2009 16:31]: [...] Is the AUTODEP_PKGNAMES portion of the rpm-pld-autodep.patch, which maps dependencies back to package names, actually useful/used by PLD? The No. It has been turned off for Th

Re: TeXLive

On Dec 7, 2008, at 4:29 AM, Łukasz Jernaś wrote: 2008/12/7 Jeff Johnson [EMAIL PROTECTED]: Heck even gasoline is now US$1.60/per gallon now ... Well, where most PLD devs/users live it's about 4.61498478 USD per gallon of super... The more interesting questions are What's

Re: TeXLive

On Dec 6, 2008, at 5:35 PM, wrobell wrote: But points noted fer sure, TeX is not easy packaging, never has been. indeed :) Note I dinna say either of (Diskspace|bandwidth) is cheap. Being stoopid is way more costly than commodity items. Ugly and evil have the same flaws.

Re: TeXLive

On Dec 6, 2008, at 6:37 PM, wrobell wrote: [1] my desktop machine is so huuug, baby Well I dunno nothin' about your desktop. But my desktop has accumulated 1,337,924.20 cobblestones patiently grinding away, mostly [EMAIL PROTECTED], through BOINC. I hope to contribute 0.005%

Re: CVSROOT: users - make AIDA Th aliases - sorted

On Nov 10, 2008, at 4:39 PM, Arkadiusz Miskiewicz wrote: What's AIDA? The wife of Rademes? ;-) ;-) Please fix sorting, you broke it. Those high notes are ever so hard to reach if you are merely a contralto ... 73 de Jeff ___ pld-devel-en

Re: SPECS: rpm.spec - 5.1.6 - updated TODO (will glob patch finally go away?)

On Oct 28, 2008, at 6:24 PM, Jan Rekorajski wrote: On Tue, 28 Oct 2008, Arkadiusz Miskiewicz wrote: On Tuesday 28 of October 2008, baggins wrote: Author: baggins Date: Tue Oct 28 22:11:56 2008 GMT Module: SPECS Tag: HEAD Log message: -

Re: SPECS: rpm.spec - 5.1.6 - updated TODO (will glob patch finally go away?)

On Oct 28, 2008, at 6:39 PM, Arkadiusz Miskiewicz wrote: On Tuesday 28 of October 2008, Jeff Johnson wrote: On Oct 28, 2008, at 6:20 PM, Arkadiusz Miskiewicz wrote: http://rpm5.org/cvs/tktview?tn=38_submit=Show really got fixed? If not fixed, I need a more precise reproducer. The problem

Re: SPECS: rpm.spec - 5.1.6 - updated TODO (will glob patch finally go away?)

On Oct 28, 2008, at 6:50 PM, Jakub Bogusz wrote: That's nothing to do with glob(). Didn't you mean: %install # (same as above) %files /* Yes. 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org

Re: SPECS: rpm.spec - 5.1.6 - updated TODO (will glob patch finally go away?)

On Oct 28, 2008, at 7:50 PM, Jeff Johnson wrote: On Oct 28, 2008, at 6:50 PM, Jakub Bogusz wrote: That's nothing to do with glob(). Didn't you mean: %install # (same as above) %files /* Yes. BTW, there's another approach to solving the glibc glob() problem pursued by SuSE if you

Re: SPECS: glibc.spec S: tzdata, too then

On Oct 27, 2008, at 4:09 AM, Elan Ruusamäe wrote: On Monday 27 October 2008 00:06, Tomasz Pala wrote: On Sun, Oct 26, 2008 at 16:32:51 -0400, Jeff Johnson wrote: Hint: read up on using %_dependency_whiteout to snip loops deterministically. The better fix, changing the packaging to not have

Re: SPECS: glibc.spec S: tzdata, too then

On Oct 26, 2008, at 4:08 PM, Tomasz Pala wrote: On Sun, Oct 26, 2008 at 21:13:28 +0300, Elan Ruusamäe wrote: +S: tzdata, too then LOOP now? Is is tight enough to cause any problems? The issue is rather different than described. Suggests: added using RPMSENSE_MISSINGOK (as PLD does)

Re: SPECS: ant.spec - unify java package (template-java.spec)

On Oct 21, 2008, at 5:20 PM, Paweł Zuzelski wrote: On Tuesday 21 of October 2008 22:32:03 Elan Ruusamäe wrote: If I understand what does %ghost mean, you should either revert my commit and then mark this file as %ghost or revert your commit. perhaps you should first understand how to

Re: SPECS (rpm-4_5): rpm.spec - deem. need different sources for db due md5

On Sep 3, 2008, at 11:15 AM, Jakub Bogusz wrote: What are profits? The profit is avoiding Berekely DB symbol clash by using --with- uniquename for rpm with internal db. Statically linking rpm will have larger bloatiness cost than what you mention. Whether you want that profit is a whole

  1   2   >