Re: [Rpm-maint] [rpm-software-management/rpm] Problem with --signfiles for files that are hardlinked together (#333)
@pmatilai Is the problem limited to the fsmMkfile() function? I suppose this is where the hard links are created. Would the solution be to do things in a different order in that function ? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/333#issuecomment-339472149___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Invoke python-macro-helper with -Es python args (#341)
> I don't think that passing -E is good Could you elaborate on that a bit, especially when you think -s /is/ good? Without -s, code from user site packages is loaded, potentially interfering with the commands. Without -E, PYTHONPATH from environment can be used to do exactly the same. (If python3 could be assumed, I would have used -I here. Which BTW is what I did in https://bugzilla.redhat.com/show_bug.cgi?id=1506355) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/341#issuecomment-339453344___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Invoke python-macro-helper with -Es python args (#341)
ignatenkobrain commented on this pull request. I don't think that passing -E is good (while -s is definitely good idea). We are planning to do same for dnf, the only -s part... As requested by Python maintainers -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/341#pullrequestreview-71979216___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Invoke python-macro-helper with -Es python args (#341)
To limit environment and user home dir influence. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/341 -- Commit Summary -- * Invoke python-macro-helper with -Es python args -- File Changes -- M macros.in (6) M scripts/python-macro-helper (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/341.patch https://github.com/rpm-software-management/rpm/pull/341.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/341 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] error: Failed to initialize NSS library (#340)
```bash root@freebsd:~ # /usr/local/rpm/bin/rpmbuild -bb curl.spec error: Failed to initialize NSS library ``` I install rpm in my FreeBSD 11.1 from source code. rpm version: ```bash root@freebsd:~ # /usr/local/rpm/bin/rpmbuild --version RPM version 4.13.0.1 ``` other package version: ```bash nspr-4.17.0 nss-3.33 db-5.3.28 ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/340___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use C.UTF-8 locale, if available (#227)
Does anyone even know anyone in the glibc community to check and see if this is even going to happen at all? Universal UTF-8 would be awesome, but right now it's only available via patched glibc in Fedora, openSUSE, and Debian. It's not available in Mageia or most other distributions who are probably not even aware of the patch in the first place. I'm also not particularly comfortable with the way we're doing this. Is there no better way to do this without adding more horrible `.in` files? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/227#issuecomment-339372109___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix Python bindings library path for custom prefix. (#327)
Hi maintainers of the RPM! Why this PR has not been merged yet? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/327#issuecomment-339370535___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Drowning in build-ids
On 10/25/2017 02:06 PM, Mark Wielaard wrote: On Wed, 2017-10-25 at 12:49 +0200, Igor Gnatenko wrote: On Wed, 2017-10-25 at 13:46 +0300, Panu Matilainen wrote: So I'm wondering how to make this less ugly. The first thing that comes to mind is adding a %hidden virtual attribute and using it on build-ids (which are in a hidden directory on the filesystem), which would hide such files rpm -ql etc output by default (but with a cli-switch to show it all). Another option would be hiding files and directories starting with dot, ie mirror the filesystem behavior. Obviously with a switch to show them too. The idea of being able to hide arbitrary files from default output makes me a bit queasy. And also %hidden wouldn't help with existing packages, (mass) rebuilds are needed with that option. So it seems like two points in favor of the fs behavior, but dunno. Thoughts, comments, better ideas? I definitely like FS approach (2). But also having %hidden (1) would find its use I think. I don't like the name %hidden, but I think that having an official attribute like "%artificial" might be the correct way to go. Then any file added by rpm/file trigger/etc that wasn't explicitly mentioned in the spec %files list could get that attribute. If you have that then you can have a rpm -qA to list all "artificial" files of the rpm (and rpm -qlA would show all). I don't really like it either. Actually the very first idea I had was to simply add build-id's as a virtual attribute of their own, ie %buildid, and callers/users could then decide whether they want to see them or not. But it seemed a bit limiting (what if we grow more data like this in the future) so I came up with "hidden", but those are entirely different kinds of concepts. I don't like the hide .dot files heuristic. People might have explicitly added .dot files to their spec %files. Then I think they should be shown by default I think. There's that, yes. But maybe explicitly treat /.build-id/ as artificial and then add an official %artificial for all "future" use would be a good compromise? Yeah, %artificial would be more like "build-id concept broadened", as opposed to "hidden" which is something completely different. Inspired by that, %artifact would also seem fairly fitting. - Panu - Cheers, Mark ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't modify interupts if db is read only (#251)
I'm actually curious as to what the use-case for this patch is, because at least with the cli tools of rpm itself, queries and the like have "always" stopped fast enough with the existing polling mechanism. Now that transactions run with signals blocked, we could move the signal polls into the various iter-next functions if that helps, but that wouldn't help anything if it's some other software (depsolvers etc) that's not polling for interrupts in their own busy-loops. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/251#issuecomment-339296375___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Drowning in build-ids
On Wed, 2017-10-25 at 12:49 +0200, Igor Gnatenko wrote: > On Wed, 2017-10-25 at 13:46 +0300, Panu Matilainen wrote: > So I'm wondering how to make this less ugly. > > > > The first thing that comes to mind is adding a %hidden virtual > > attribute > > and using it on build-ids (which are in a hidden directory on the > > filesystem), which would hide such files rpm -ql etc output by > > default > > (but with a cli-switch to show it all). > > > > Another option would be hiding files and directories starting with > > dot, > > ie mirror the filesystem behavior. Obviously with a switch to show > > them too. > > > > The idea of being able to hide arbitrary files from default output > > makes > > me a bit queasy. And also %hidden wouldn't help with existing > > packages, > > (mass) rebuilds are needed with that option. So it seems like two > > points > > in favor of the fs behavior, but dunno. > > > > Thoughts, comments, better ideas? > > I definitely like FS approach (2). But also having %hidden (1) would > find its use I think. I don't like the name %hidden, but I think that having an official attribute like "%artificial" might be the correct way to go. Then any file added by rpm/file trigger/etc that wasn't explicitly mentioned in the spec %files list could get that attribute. If you have that then you can have a rpm -qA to list all "artificial" files of the rpm (and rpm -qlA would show all). I don't like the hide .dot files heuristic. People might have explicitly added .dot files to their spec %files. Then I think they should be shown by default I think. But maybe explicitly treat /.build-id/ as artificial and then add an official %artificial for all "future" use would be a good compromise? Cheers, Mark ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Drowning in build-ids
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2017-10-25 at 13:46 +0300, Panu Matilainen wrote: > I've only now begun to encounter packages with the build-id links in > the > packages themselves. In a package with just a couple of binaries > it's > seemed like non-issue, but yesterday I happened to encounter this: > > [pmatilai@sopuli x86_64]$ rpm -qpl can-utils-20170830git- > 1.fc28.x86_64.rpm > /usr/bin/asc2log > /usr/bin/bcmserver > /usr/bin/can-calc-bit-timing > /usr/bin/canbusload > /usr/bin/candump > /usr/bin/canfdtest > /usr/bin/cangen > /usr/bin/cangw > /usr/bin/canlogserver > /usr/bin/canplayer > /usr/bin/cansend > /usr/bin/cansniffer > /usr/bin/isotpdump > /usr/bin/isotpperf > /usr/bin/isotprecv > /usr/bin/isotpsend > /usr/bin/isotpserver > /usr/bin/isotpsniffer > /usr/bin/isotptun > /usr/bin/log2asc > /usr/bin/log2long > /usr/bin/slcan_attach > /usr/bin/slcand > /usr/bin/slcanpty > /usr/lib/.build-id > /usr/lib/.build-id/05 > /usr/lib/.build-id/05/c6e0445041bc297383997257bb625809ba62cb > /usr/lib/.build-id/0a > /usr/lib/.build-id/0a/60db326d39a38847a3f6c6bb67213434399c42 > /usr/lib/.build-id/0a/7395e63809014439634b0f1c311b40a05fb5e5 > /usr/lib/.build-id/1a > /usr/lib/.build-id/1a/cd09a44512470d5376a5abee7438005b3de0a2 > /usr/lib/.build-id/24 > /usr/lib/.build-id/24/c4eb684e21826207dc1d71bc023cdef7b5ee88 > /usr/lib/.build-id/3a > /usr/lib/.build-id/3a/2309e9e68c2e3cdf475734b7eb4f426f109926 > /usr/lib/.build-id/3f > /usr/lib/.build-id/3f/cd554bc60888e7feb4fb3d4cb891c549361aed > /usr/lib/.build-id/59 > /usr/lib/.build-id/59/c1638a4c15139492927c117d44cc6f84532464 > /usr/lib/.build-id/5b > /usr/lib/.build-id/5b/c0f8af0212d1e94f8a5c962b719dbe3f4dcc50 > /usr/lib/.build-id/6a > /usr/lib/.build-id/6a/187c01913bc9b861dcb95ac0c5a12865fdd93b > /usr/lib/.build-id/6a/47c3475fbe4303a8a8005353f11f719112f838 > /usr/lib/.build-id/71 > /usr/lib/.build-id/71/f3b492130fa6ae09354107a8d7821d2969a4d9 > /usr/lib/.build-id/75 > /usr/lib/.build-id/75/a05d7dd3d81d9f7c0eef1ebde082cc1a5c93d9 > /usr/lib/.build-id/7d > /usr/lib/.build-id/7d/2f0e2ceb4580c3ccd865e689bce9beb3a20903 > /usr/lib/.build-id/7e > /usr/lib/.build-id/7e/ac33ea6338f316f03476c70f7c2d3743104a68 > /usr/lib/.build-id/8a > /usr/lib/.build-id/8a/40a26934006152ad167875b61497065cbe3f7e > /usr/lib/.build-id/9e > /usr/lib/.build-id/9e/1b2107379d4830ecf3da8c29faf8e558c1eac2 > /usr/lib/.build-id/b0 > /usr/lib/.build-id/b0/ca696ceaa3a1e54722483ee55c5b12883d44f0 > /usr/lib/.build-id/b3 > /usr/lib/.build-id/b3/90fe4f2ac3dcea04aacf34b46b858466626a2e > /usr/lib/.build-id/c6 > /usr/lib/.build-id/c6/645447744a17cc09f175e4d1f3bd8a441e1563 > /usr/lib/.build-id/db > /usr/lib/.build-id/db/84b0bc26c9bb0eadc88a8ecde185e3db6452ba > /usr/lib/.build-id/f3 > /usr/lib/.build-id/f3/5c37a5dc142928053784cb072403988b0f65dc > /usr/lib/.build-id/fb > /usr/lib/.build-id/fb/46eef57284d7136974be48fba4b0550a86c998 > /usr/lib/.build-id/fc > /usr/lib/.build-id/fc/e691679c6ac99d2940daf63c6fe3221ee1af77 > /usr/share/doc/can-utils > /usr/share/doc/can-utils/README.md > /usr/share/licenses/can-utils > /usr/share/licenses/can-utils/COPYING > [pmatilai@sopuli x86_64]$ > > I typically use 80x35 terminals and even on that, what you end up > seeing > is the hex gibberish of build-ids that is totally irrelevant for > most > people completely dominates the output that used to be spot-on > relevant. > Not good. > > So I'm wondering how to make this less ugly. > > The first thing that comes to mind is adding a %hidden virtual > attribute > and using it on build-ids (which are in a hidden directory on the > filesystem), which would hide such files rpm -ql etc output by > default > (but with a cli-switch to show it all). > > Another option would be hiding files and directories starting with > dot, > ie mirror the filesystem behavior. Obviously with a switch to show > them too. > > The idea of being able to hide arbitrary files from default output > makes > me a bit queasy. And also %hidden wouldn't help with existing > packages, > (mass) rebuilds are needed with that option. So it seems like two > points > in favor of the fs behavior, but dunno. > > Thoughts, comments, better ideas? I definitely like FS approach (2). But also having %hidden (1) would find its use I think. > > - Panu - > ___ > Rpm-maint mailing list > Rpm-maint@lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-maint - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlnwbCsACgkQaVcUvRu8 X0yPsg/+NYPUDYV+TX4aqUB9rJ6q7OI7Mcg2w8HSobSI0KLFM3zFIO86MUyGA5Uo Bi7Od3TkXIXxYrGHL14Obh7cb9gVl0RStRo6SyTBrxIvOSAYPi2MpE+bG+O0eVPZ 16GfDZEZfADVwoRq5APUwYbQrF4gExq4jhZDsL2brwQ7dWf4pWnam9CcdrYEYIdB rXtx43t9NQfc8d0gYG/gFP3Ntqsbhslrbfip/1+Ff0lwh14QsHSKGVbs8X3o897K /iVRhX9ocvjRyWfIPaZ22bRfAj0bv78P08l5ki2xRs7K7okjgyhW3DzPqmdZeJ9S 1e5FNHOM0t6et1J3BfB8vfiwL3PG2ue9NdnIOd61nPPIaNgZK50gzrUN/z3w3NL5
[Rpm-maint] Drowning in build-ids
I've only now begun to encounter packages with the build-id links in the packages themselves. In a package with just a couple of binaries it's seemed like non-issue, but yesterday I happened to encounter this: [pmatilai@sopuli x86_64]$ rpm -qpl can-utils-20170830git-1.fc28.x86_64.rpm /usr/bin/asc2log /usr/bin/bcmserver /usr/bin/can-calc-bit-timing /usr/bin/canbusload /usr/bin/candump /usr/bin/canfdtest /usr/bin/cangen /usr/bin/cangw /usr/bin/canlogserver /usr/bin/canplayer /usr/bin/cansend /usr/bin/cansniffer /usr/bin/isotpdump /usr/bin/isotpperf /usr/bin/isotprecv /usr/bin/isotpsend /usr/bin/isotpserver /usr/bin/isotpsniffer /usr/bin/isotptun /usr/bin/log2asc /usr/bin/log2long /usr/bin/slcan_attach /usr/bin/slcand /usr/bin/slcanpty /usr/lib/.build-id /usr/lib/.build-id/05 /usr/lib/.build-id/05/c6e0445041bc297383997257bb625809ba62cb /usr/lib/.build-id/0a /usr/lib/.build-id/0a/60db326d39a38847a3f6c6bb67213434399c42 /usr/lib/.build-id/0a/7395e63809014439634b0f1c311b40a05fb5e5 /usr/lib/.build-id/1a /usr/lib/.build-id/1a/cd09a44512470d5376a5abee7438005b3de0a2 /usr/lib/.build-id/24 /usr/lib/.build-id/24/c4eb684e21826207dc1d71bc023cdef7b5ee88 /usr/lib/.build-id/3a /usr/lib/.build-id/3a/2309e9e68c2e3cdf475734b7eb4f426f109926 /usr/lib/.build-id/3f /usr/lib/.build-id/3f/cd554bc60888e7feb4fb3d4cb891c549361aed /usr/lib/.build-id/59 /usr/lib/.build-id/59/c1638a4c15139492927c117d44cc6f84532464 /usr/lib/.build-id/5b /usr/lib/.build-id/5b/c0f8af0212d1e94f8a5c962b719dbe3f4dcc50 /usr/lib/.build-id/6a /usr/lib/.build-id/6a/187c01913bc9b861dcb95ac0c5a12865fdd93b /usr/lib/.build-id/6a/47c3475fbe4303a8a8005353f11f719112f838 /usr/lib/.build-id/71 /usr/lib/.build-id/71/f3b492130fa6ae09354107a8d7821d2969a4d9 /usr/lib/.build-id/75 /usr/lib/.build-id/75/a05d7dd3d81d9f7c0eef1ebde082cc1a5c93d9 /usr/lib/.build-id/7d /usr/lib/.build-id/7d/2f0e2ceb4580c3ccd865e689bce9beb3a20903 /usr/lib/.build-id/7e /usr/lib/.build-id/7e/ac33ea6338f316f03476c70f7c2d3743104a68 /usr/lib/.build-id/8a /usr/lib/.build-id/8a/40a26934006152ad167875b61497065cbe3f7e /usr/lib/.build-id/9e /usr/lib/.build-id/9e/1b2107379d4830ecf3da8c29faf8e558c1eac2 /usr/lib/.build-id/b0 /usr/lib/.build-id/b0/ca696ceaa3a1e54722483ee55c5b12883d44f0 /usr/lib/.build-id/b3 /usr/lib/.build-id/b3/90fe4f2ac3dcea04aacf34b46b858466626a2e /usr/lib/.build-id/c6 /usr/lib/.build-id/c6/645447744a17cc09f175e4d1f3bd8a441e1563 /usr/lib/.build-id/db /usr/lib/.build-id/db/84b0bc26c9bb0eadc88a8ecde185e3db6452ba /usr/lib/.build-id/f3 /usr/lib/.build-id/f3/5c37a5dc142928053784cb072403988b0f65dc /usr/lib/.build-id/fb /usr/lib/.build-id/fb/46eef57284d7136974be48fba4b0550a86c998 /usr/lib/.build-id/fc /usr/lib/.build-id/fc/e691679c6ac99d2940daf63c6fe3221ee1af77 /usr/share/doc/can-utils /usr/share/doc/can-utils/README.md /usr/share/licenses/can-utils /usr/share/licenses/can-utils/COPYING [pmatilai@sopuli x86_64]$ I typically use 80x35 terminals and even on that, what you end up seeing is the hex gibberish of build-ids that is totally irrelevant for most people completely dominates the output that used to be spot-on relevant. Not good. So I'm wondering how to make this less ugly. The first thing that comes to mind is adding a %hidden virtual attribute and using it on build-ids (which are in a hidden directory on the filesystem), which would hide such files rpm -ql etc output by default (but with a cli-switch to show it all). Another option would be hiding files and directories starting with dot, ie mirror the filesystem behavior. Obviously with a switch to show them too. The idea of being able to hide arbitrary files from default output makes me a bit queasy. And also %hidden wouldn't help with existing packages, (mass) rebuilds are needed with that option. So it seems like two points in favor of the fs behavior, but dunno. Thoughts, comments, better ideas? - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] error in the docs (at rpm.org): exclamation mark is missing (#339)
Fixed now, thanks for reporting. In the future, please report website issues to the website tracker instead: https://github.com/rpm-software-management/rpm-web/issues -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/339#issuecomment-339273851___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use C.UTF-8 locale, if available (#227)
I'd have less reservations about this if it was upstreamed in glibc, but there doesn't seem to be any activity in the last 2.5 years which is not so encouraging. The other thing is that I *hate* those .in files and this adds a whole pile more of them. They are all scripts invoked by rpmbuild internally, so we could just set the locale from doScript() once and remove the duplicated locale setting from a whole number of places instead of complicating it. But it'd of course be nice if the scripts behaved reasonably when invoked directly too (for debugging etc). Dunno. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/227#issuecomment-339272486___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Find lang.sh multi names (#235)
Changelogs embedded in individual files don't belong to a project maintained in a VCS to begin with. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/235#issuecomment-339250736___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Python macro improvements (#221)
Merged #221. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/221#event-1309319368___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Python macro improvements (#221)
Dropped the ball with this one, sorry. Also missed the fact the shebang is not used in the actual macro invocation, so withdrawing my grumblings. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/221#issuecomment-339249291___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] tests: add tests for rich dependencies (#326)
Cleaned up some trailing whitespace and applied manually (commit 2e835509a62b7806e010292f354a3fa6e9830dc3). Thanks! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/326#issuecomment-339246717___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
