From glen at pld-linux.org Wed Jun 1 00:30:39 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 1 Jun 2016 01:30:39 +0300 Subject: ldconfig forgotten In-Reply-To: References: <574D3317.4040404@pld-linux.org> <574D34A8.2060806@pld-linux.org> <41DAD6A9-495A-4CA4-A828-0DBDC9674BAA@mac.com> <574DF502.9010309@pld-linux.org> <574DC18A-BDCD-4DC6-B339-41BF7E562A62@mac.com> <574DF850.5000700@pld-linux.org> Message-ID: <574E108F.6000201@pld-linux.org> 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% reproducible testcase -- ps command was usable after package was just installed i posted the rpm -vvv output to the list as well. -- glen From n3npq at mac.com Wed Jun 1 00:45:00 2016 From: n3npq at mac.com (Jeff Johnson) Date: Tue, 31 May 2016 18:45:00 -0400 Subject: ldconfig forgotten In-Reply-To: <574E108F.6000201@pld-linux.org> References: <574D3317.4040404@pld-linux.org> <574D34A8.2060806@pld-linux.org> <41DAD6A9-495A-4CA4-A828-0DBDC9674BAA@mac.com> <574DF502.9010309@pld-linux.org> <574DC18A-BDCD-4DC6-B339-41BF7E562A62@mac.com> <574DF850.5000700@pld-linux.org> <574E108F.6000201@pld-linux.org> Message-ID: 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% reproducible testcase -- ps command was usable after package was just installed > Good, fixed. There's likely a slightly better fix, by limiting the skipping of /sbin/ldconfig to only removed packages on upgrade, if anyone is interested. At worst, there will be dangling unused symlinks that the skipped /sbin/ldconfig would have removed. *shrug* 73 de Jeff From glen at pld-linux.org Wed Jun 1 13:41:24 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 1 Jun 2016 14:41:24 +0300 Subject: pld-release 3.0-8 Message-ID: <574EC9E4.5070504@pld-linux.org> https://github.com/pld-linux/pld-release/commit/7a6cd5ad9a461d27f92c0cf1401961b179338812 why such change? the file contents is far from compatible "their" version is: ours: $ cat /etc/system-release 3.0 PLD Linux (Th) theirs: $ cat /etc/system-release CentOS Linux release 7.2.1511 (Core) and this totally breaks ohai: https://github.com/chef/ohai/blob/7.4-stable/lib/ohai/plugins/linux/platform.rb#L23-L29 results "3" for get_redhatish_platform and nil for get_redhatish_version -- glen From glen at pld-linux.org Thu Jun 2 00:29:28 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 2 Jun 2016 01:29:28 +0300 Subject: python3 optional deps In-Reply-To: <9dda8ba8-9f62-d705-7da0-ff4bdae56924@jajcus.net> References: <5729BCAB.3040402@pld-linux.org> <572C4AB5.4060800@pld-linux.org> <7785aa5d-eae0-bb9a-214d-1083305e7ba1@jajcus.net> <572C5CE5.7070607@pld-linux.org> <9dda8ba8-9f62-d705-7da0-ff4bdae56924@jajcus.net> Message-ID: <574F61C8.4040108@pld-linux.org> On 06.05.2016 14:36, Jacek Konieczny wrote: > On 2016-05-06 10:59, Elan Ruusam?e wrote: >> On 06.05.2016 11:47, Jacek Konieczny wrote: >>> >>> Feel free to separate it :-) >> sure. suggest package name? > > rpm-pythonprov? It is already a separate package, just built with > whole RPM. > >> >> looks like there's just one file to move: >> /usr/lib/rpm/pythoneggs.py > > > [jajcus at jajo ~]$ rpm -ql rpm-pythonprov > /usr/lib/rpm/pythondeps.sh > /usr/lib/rpm/pythoneggs.py while i didn't actually solve the previous problem, i've hit similar problem with making change to gem_helper.rb https://github.com/pld-linux/rpm/commit/d2eb086f435776799b4bde76f34ecd5f67eb171f the change should be versioned, so .spec files could use it, it being built from rpm.spec means the dep should be rpm version specific, which i do not like: 1. were in middle of 5.4.15 -> 5.4.17 change 2. the change isn't in rpm code at all 3. some (qboosh?) still uses his own rpm build (rpm4.5?) 4. pld-ac also uses rpm4.5, altho it's probably not affected for these two cases (python and ruby) so, move all those *prov* packages from rpm.spec to rpm-build-macros package? these are never going to be using upstream files, we always patch them. (and this doesn't prevent time to time submitting them to upstream) -- glen From qboosh at pld-linux.org Fri Jun 3 20:38:28 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 3 Jun 2016 20:38:28 +0200 Subject: pld-release 3.0-8 In-Reply-To: <574EC9E4.5070504@pld-linux.org> References: <574EC9E4.5070504@pld-linux.org> Message-ID: <20160603183828.GA16693@mail> On Wed, Jun 01, 2016 at 02:41:24PM +0300, Elan Ruusam?e wrote: > https://github.com/pld-linux/pld-release/commit/7a6cd5ad9a461d27f92c0cf1401961b179338812 > > why such change? Some software use this path (/etc/system-release). libreport failed during system detection before this change; it resulted in tests failing. > the file contents is far from compatible "their" version is: > > ours: > $ cat /etc/system-release > 3.0 PLD Linux (Th) > > theirs: > $ cat /etc/system-release > CentOS Linux release 7.2.1511 (Core) > > and this totally breaks ohai: > > https://github.com/chef/ohai/blob/7.4-stable/lib/ohai/plugins/linux/platform.rb#L23-L29 > > results "3" for get_redhatish_platform and nil for get_redhatish_version Feel free to replace symlink with a separate file with more suitable contents, if you know the expected syntax. -- Jakub Bogusz http://qboosh.pl/ From n3npq at mac.com Sun Jun 5 20:06:12 2016 From: n3npq at mac.com (Jeff Johnson) Date: Sun, 05 Jun 2016 14:06:12 -0400 Subject: rpm needs db-6.1.26+ patch (was Re: python3 optional deps) In-Reply-To: <574F61C8.4040108@pld-linux.org> References: <5729BCAB.3040402@pld-linux.org> <572C4AB5.4060800@pld-linux.org> <7785aa5d-eae0-bb9a-214d-1083305e7ba1@jajcus.net> <572C5CE5.7070607@pld-linux.org> <9dda8ba8-9f62-d705-7da0-ff4bdae56924@jajcus.net> <574F61C8.4040108@pld-linux.org> Message-ID: <53A728E7-8CA4-4FD1-B02F-5E91D2404754@mac.com> 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 ====================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: jbj13.patch Type: application/octet-stream Size: 573 bytes Desc: not available URL: From qboosh at pld-linux.org Sun Jun 5 21:51:32 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 5 Jun 2016 21:51:32 +0200 Subject: Insecure /run permissions Message-ID: <20160605195132.GA27650@mail> While doing FHS 3.0 research (I'm finishing FHS.spec update by the way) I found that /run is mounted by rc.sysinit with insecure permissions (default for tmpfs, but not appropriate for this directory): 3.15. /run : Run-time variable data [...] Programs may have a subdirectory of /run; this is encouraged for programs that use more than one run-time file. Users may also have a subdirectory of /run, although care must be taken to appropriately limit access rights to prevent unauthorized use of /run itself and other subdirectories. ^[17] [...] ^[17] /run should not be writable for unprivileged users; it is a major security problem if any user can write in this directory. User-specific subdirectories should be writable only by each directory's owner. So rc.sysinit needs fix to use mode=755 for /run. -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Sun Jun 5 22:28:17 2016 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Sun, 5 Jun 2016 22:28:17 +0200 Subject: Insecure /run permissions In-Reply-To: <20160605195132.GA27650@mail> References: <20160605195132.GA27650@mail> Message-ID: <201606052228.17375.arekm@maven.pl> On Sunday 05 of June 2016, Jakub Bogusz wrote: > So rc.sysinit needs fix to use mode=755 for /run. geninitrd, too then -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at delfi.ee Mon Jun 6 21:00:38 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 6 Jun 2016 22:00:38 +0300 Subject: rpm -Uhv --oldpackage loses configs Message-ID: <5755C856.7010101@delfi.ee> (pld has --downgrade alias to --oldpackage via popt) downgrading from repackage lost config files, i.e saved them as .rpmsave leaving original path missing # ls -l */*pam* -rw-r--r-- 1 root root 326K 6. juuni 20:17 1465233457/pam-1.1.8-8.x86_64.rpm -rw-r--r-- 1 root root 35K 6. juuni 20:17 1465233457/pam-libs-1.1.8-8.x86_64.rpm root at glen spool/repackage# root at glen spool/repackage# rpm -Uhv */*pam* --downgrade warning: package pam = 1:1.1.8-8 was already added, replacing with pam >= 1:1.2.1-1 warning: package pam-libs = 1:1.1.8-8 was already added, replacing with pam-libs >= 1:1.2.1-1 Preparing... ########################################### [100%] Repackaging... 1:pam ########################################### [ 50%] 2:pam-libs ########################################### [100%] Upgrading... 1:pam-libs ########################################### [ 50%] warning: /etc/security/namespace.init saved as /etc/security/namespace.init.rpmsave warning: /etc/security/limits.conf saved as /etc/security/limits.conf.rpmsave warning: /etc/pam.d/system-auth saved as /etc/pam.d/system-auth.rpmsave 2:pam ########################################### [100%] root at glen spool/repackage# cd /etc/security/ root at glen /etc/security# rpm -qf namespace.init pam-1.2.1-1.x86_64 root at glen /etc/security# mv -bi namespace.init.rpmsave namespace.init root at glen /etc/security# cd /etc/security/ root at glen /etc/security# mv -bi limits.conf.rpmsave limits.conf root at glen /etc/security# mv -bi /etc/pam.d/system-auth.rpmsave /etc/pam.d/system-auth root at glen /etc/security# # rpm -q rpm rpm-5.4.15-33.x86_64 -- glen From n3npq at me.com Mon Jun 6 23:00:23 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 06 Jun 2016 17:00:23 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <5755C856.7010101@delfi.ee> References: <5755C856.7010101@delfi.ee> Message-ID: <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> > On Jun 6, 2016, at 3:00 PM, Elan Ruusam?e wrote: > > (pld has --downgrade alias to --oldpackage via popt) > > downgrading from repackage lost config files, > i.e saved them as .rpmsave leaving original path missing > > # ls -l */*pam* > -rw-r--r-- 1 root root 326K 6. juuni 20:17 1465233457/pam-1.1.8-8.x86_64.rpm > -rw-r--r-- 1 root root 35K 6. juuni 20:17 1465233457/pam-libs-1.1.8-8.x86_64.rpm > > root at glen spool/repackage# > root at glen spool/repackage# rpm -Uhv */*pam* --downgrade > warning: package pam = 1:1.1.8-8 was already added, replacing with pam >= 1:1.2.1-1 > warning: package pam-libs = 1:1.1.8-8 was already added, replacing with pam-libs >= 1:1.2.1-1 > Preparing... ########################################### [100%] > Repackaging... > 1:pam ########################################### [ 50%] > 2:pam-libs ########################################### [100%] > Upgrading... > 1:pam-libs ########################################### [ 50%] > warning: /etc/security/namespace.init saved as /etc/security/namespace.init.rpmsave > warning: /etc/security/limits.conf saved as /etc/security/limits.conf.rpmsave > warning: /etc/pam.d/system-auth saved as /etc/pam.d/system-auth.rpmsave > 2:pam ########################################### [100%] > > root at glen spool/repackage# cd /etc/security/ > root at glen /etc/security# rpm -qf namespace.init > pam-1.2.1-1.x86_64 > > root at glen /etc/security# mv -bi namespace.init.rpmsave namespace.init > root at glen /etc/security# cd /etc/security/ > root at glen /etc/security# mv -bi limits.conf.rpmsave limits.conf > root at glen /etc/security# mv -bi /etc/pam.d/system-auth.rpmsave /etc/pam.d/system-auth > root at glen /etc/security# > > # rpm -q rpm > rpm-5.4.15-33.x86_64 > What exactly are you expecting? I see rpm renaming modified %config files to *.rpmsave exactly as always, nothing more. FWIW: there is no ?downgrade in rpm, and flipping various bits in polled to disable version comparisons and file conflicts in order to achieve ?downgrade? has almost nothing to do with %config handling. 73 de Jeff > > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From gotar at polanet.pl Tue Jun 7 05:04:33 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 7 Jun 2016 05:04:33 +0200 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> Message-ID: <20160607030433.GA22086@polanet.pl> On Mon, Jun 06, 2016 at 17:00:23 -0400, Jeffrey Johnson wrote: >> downgrading from repackage lost config files, >> i.e saved them as .rpmsave leaving original path missing [...] > What exactly are you expecting? If previous (modified) configs were moved to .rpmsave, anyone should expect package-provided files to be put in place. > I see rpm renaming modified %config files to *.rpmsave exactly as always, nothing more. But doesn't install files that were to replace them. > FWIW: there is no ???downgrade in rpm, and flipping various bits in polled to disable version comparisons > and file conflicts in order to achieve ???downgrade??? has almost nothing to do with %config handling. I guess this is related to using repackaged.rpm. These types of packages are known to have manifest different than real contents, so while installing one might expect such behaviour. -- Tomasz Pala From n3npq at me.com Tue Jun 7 05:33:58 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 06 Jun 2016 23:33:58 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <20160607030433.GA22086@polanet.pl> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> Message-ID: <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> > On Jun 6, 2016, at 11:04 PM, Tomasz Pala wrote: > > On Mon, Jun 06, 2016 at 17:00:23 -0400, Jeffrey Johnson wrote: > >>> downgrading from repackage lost config files, >>> i.e saved them as .rpmsave leaving original path missing > [...] >> What exactly are you expecting? > > If previous (modified) configs were moved to .rpmsave, anyone should > expect package-provided files to be put in place. > That depends on the ordering of remove vs install. RPM (and most of its algorithms) depends on install-before-erase. The mere fact that files were renamed to *.rpmsave indicates that remove-before-install was occurring. >> I see rpm renaming modified %config files to *.rpmsave exactly as always, nothing more. > > But doesn't install files that were to replace them. > Really? There is nothing in the e-mail report that indicates that files were not installed. There is an indication that the original (and modified) contents were renamed and had to be manually moved back into place. Again, I do not know what is ?expected? ? what is being reported is what I expect to see (and there is no ?loses? in renaming to *.rpmsave). (aside) Yes having to deal with %config renaming is quite tedious. I personally believe that all of %config is fabulously broken and useless. Meanwhile, my obligation is to ensure that the current mechanism ?works? in rpm exactly as it is supposed to work, not otherwise. >> FWIW: there is no ???downgrade in rpm, and flipping various bits in polled to disable version comparisons >> and file conflicts in order to achieve ???downgrade??? has almost nothing to do with %config handling. > > I guess this is related to using repackaged.rpm. These types of packages > are known to have manifest different than real contents, so while installing > one might expect such behavior. > I?m not sure how repackaged rpm?s are involved: that isn?t entirely clear from the report. Yes, the header?s in repackaged *.rpm?s have additional tags (of a doubly linked package upgrade chain) appended. And repackaged *.rpm?s are *entirely* best effort. Content may be missing and/or modified: whatever is on the file system when the repackaging occurs is what is loaded into the repackaged rpm. There is nothing in the report that indicates the necessary disablers were used: you can *NOT* just reinstall a repackaged package without additional flags. Presumably those additional flags are buried in the ?downgrade alias added by PLD. I have little experience (and certainly no test cases) with how rpm behaves with PLD modifications. Better could and should be done in rpm. But it takes more than repeated complaints of ?losing? or ?destroying? %config files from heavily modified versions of rpm to achieve development. Meanwhile RPM is doing exactly what I expect, knowing what is implemented. 73 de Jeff From glen at delfi.ee Tue Jun 7 10:34:04 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 11:34:04 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> Message-ID: <575686FC.9050809@delfi.ee> On 07.06.2016 06:33, Jeffrey Johnson wrote: >>> I see rpm renaming modified %config files to *.rpmsave exactly as always, nothing more. >> > >> >But doesn't install files that were to replace them. >> > > Really? There is nothing in the e-mail report that indicates that files were not installed. i said in first lines on email: > (pld has --downgrade alias to --oldpackage via popt) > downgrading from repackage lost config files, > i.e saved them as .rpmsave leaving original path missing meaning that: 1. --downgrade is alias to --oldpackage 2. the files marked as %config were missing, i.e /etc/config was missing, only /etc/config.rpmsave present, leaving application broken i.e renamed to .rpmsave while base config was not kept. -- glen From glen at delfi.ee Tue Jun 7 10:35:01 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 11:35:01 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> Message-ID: <57568735.3090302@delfi.ee> On 07.06.2016 06:33, Jeffrey Johnson wrote: > I?m not sure how repackaged rpm?s are involved: that isn?t entirely clear from the report. again, it was included in report that files were installed from repackage pool: # ls -l */*pam* -rw-r--r-- 1 root root 326K 6. juuni 20:17 1465233457/pam-1.1.8-8.x86_64.rpm -rw-r--r-- 1 root root 35K 6. juuni 20:17 1465233457/pam-libs-1.1.8-8.x86_64.rpm root at glen spool/repackage# root at glen spool/repackage# rpm -Uhv */*pam* --downgrade -- glen From qboosh at pld-linux.org Tue Jun 7 16:21:27 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 7 Jun 2016 16:21:27 +0200 Subject: [projects/geninitrd] Mount /run with 0755. In-Reply-To: <583a7f5f8783fb1f92b75ca9f651d675df016b73_refs_heads_master@pld-linux.org> References: <11202855dbaee5bc32209913df1ae8738c210c39_refs_heads_master@pld-linux.org> <583a7f5f8783fb1f92b75ca9f651d675df016b73_refs_heads_master@pld-linux.org> Message-ID: <20160607142127.GA7707@mail> On Tue, Jun 07, 2016 at 08:30:57AM +0200, arekm wrote: > commit 583a7f5f8783fb1f92b75ca9f651d675df016b73 > Author: Arkadiusz Mi?kiewicz > Date: Tue Jun 7 08:30:46 2016 +0200 > > Mount /run with 0755. [...] > - echo "mount -t tmpfs run /run" | add_linuxrc > + echo "mount -t tmpfs run /run -o mode=0755" | add_linuxrc I'd suggest also noexec,nosuid... not sure about nodev (Debian/Ubuntu don't use nodev for /run, I saw it in some report from other distro) -- Jakub Bogusz http://qboosh.pl/ From n3npq at me.com Tue Jun 7 16:31:29 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 07 Jun 2016 10:31:29 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <57568735.3090302@delfi.ee> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> <57568735.3090302@delfi.ee> Message-ID: <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> > On Jun 7, 2016, at 4:35 AM, Elan Ruusam?e wrote: > > On 07.06.2016 06:33, Jeffrey Johnson wrote: >> I?m not sure how repackaged rpm?s are involved: that isn?t entirely clear from the report. > again, it was included in report that files were installed from repackage pool: > Its still not clear to me whether the new package files were installed or not. Yes the original configuration files were renamed to *.rpmsave. > > # ls -l */*pam* > -rw-r--r-- 1 root root 326K 6. juuni 20:17 1465233457/pam-1.1.8-8.x86_64.rpm > -rw-r--r-- 1 root root 35K 6. juuni 20:17 1465233457/pam-libs-1.1.8-8.x86_64.rpm > > root at glen spool/repackage# > root at glen spool/repackage# rpm -Uhv */*pam* ?d OK, so repackaged *.rpm were used. The repackaged rpm?s are ?best effort?: if the files are renamed before the repackaging occurs, then those packages do not contain the config files because the files were not present (on the original path) when the repackaging occurred. Do the repackaged rpm?s contain those files.? When/how were the repackaged packages created? 73 de Jeff > owngrade > > > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From glen at delfi.ee Tue Jun 7 16:37:19 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 17:37:19 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> <57568735.3090302@delfi.ee> <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> Message-ID: <5756DC1F.2000204@delfi.ee> 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... -- glen From n3npq at mac.com Tue Jun 7 16:39:42 2016 From: n3npq at mac.com (Jeff Johnson) Date: Tue, 07 Jun 2016 10:39:42 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <5756DC1F.2000204@delfi.ee> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> <57568735.3090302@delfi.ee> <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> <5756DC1F.2000204@delfi.ee> Message-ID: <9B25F23C-7A4F-4D03-A2E8-43427AC384CD@mac.com> 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. Were the files present on the file system (presumably not, but I'd like confirmation)? Do the repackaged rpm?s contain those files.? When/how were the repackaged packages created? 73 de Jeff From glen at delfi.ee Tue Jun 7 16:44:54 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 17:44:54 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> <57568735.3090302@delfi.ee> <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> Message-ID: <5756DDE6.4090309@delfi.ee> On 07.06.2016 17:31, Jeffrey Johnson wrote: >> ># ls -l */*pam* >> >-rw-r--r-- 1 root root 326K 6. juuni 20:17 1465233457/pam-1.1.8-8.x86_64.rpm >> >-rw-r--r-- 1 root root 35K 6. juuni 20:17 1465233457/pam-libs-1.1.8-8.x86_64.rpm >> > >> >root at glen spool/repackage# >> >root at glen spool/repackage# rpm -Uhv */*pam* ?d > OK, so repackaged *.rpm were used. > > The repackaged rpm?s are ?best effort?: if the files are renamed before > the repackaging occurs, then those packages do not contain the config > files because the files were not present (on the original path) when the > repackaging occurred. come on! the files were removed when i installed from repackage pool. (see the log i pasted) NOT BEFORE. it's RPM that removed (renamed) the files, nothing superficious happened before downgrade action removing files. it's all in rpm! > 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 root root 1016 veebr 25 2015 /etc/pam.d/system-auth # rpm -qc pam|grep /etc/pam.d/system-auth /etc/pam.d/system-auth and still marked as %config > When/how were the repackaged packages created? this flag was enabled: root at glen spool/repackage# rpm -E %_repackage_all_erasures 1 and the repackaged files were created whe pam was upgraded (that pam upgrade log is not posted, it's irrelevant and i do not have it) -- glen From glen at delfi.ee Tue Jun 7 16:45:41 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 17:45:41 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <9B25F23C-7A4F-4D03-A2E8-43427AC384CD@mac.com> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> <57568735.3090302@delfi.ee> <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> <5756DC1F.2000204@delfi.ee> <9B25F23C-7A4F-4D03-A2E8-43427AC384CD@mac.com> Message-ID: <5756DE15.2080806@delfi.ee> 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 like: warning: /etc/security/namespace.init saved as /etc/security/namespace.init.rpmsave -- glen From n3npq at mac.com Tue Jun 7 16:48:51 2016 From: n3npq at mac.com (Jeff Johnson) Date: Tue, 07 Jun 2016 10:48:51 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <5756DDE6.4090309@delfi.ee> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> <57568735.3090302@delfi.ee> <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> <5756DDE6.4090309@delfi.ee> Message-ID: <694BF4B1-49E1-4948-9FC1-BFEDA9CB1305@mac.com> 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 root root 1016 veebr 25 2015 /etc/pam.d/system-auth > > # rpm -qc pam|grep /etc/pam.d/system-auth > /etc/pam.d/system-auth > > and still marked as %config Sorry for not being precise. Yes the metadata header contains those files. Are the files in the payload? rpm2cpio *.rpm | cpio -itv If the files are not in the payload, then they will not be installed. 73 de Jeff From n3npq at mac.com Tue Jun 7 16:51:27 2016 From: n3npq at mac.com (Jeff Johnson) Date: Tue, 07 Jun 2016 10:51:27 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <5756DE15.2080806@delfi.ee> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> <57568735.3090302@delfi.ee> <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> <5756DC1F.2000204@delfi.ee> <9B25F23C-7A4F-4D03-A2E8-43427AC384CD@mac.com> <5756DE15.2080806@delfi.ee> Message-ID: 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 like: > > warning: /etc/security/namespace.init saved as /etc/security/namespace.init.rpmsave > Of course the files were present when renamed. I am asking for confirmation whether the files were present _AFTER_ the upgrade/downgrade completed trying to diagnose your problem. 73 de Jeff > > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From gotar at polanet.pl Tue Jun 7 18:18:36 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 7 Jun 2016 18:18:36 +0200 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <694BF4B1-49E1-4948-9FC1-BFEDA9CB1305@mac.com> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> <57568735.3090302@delfi.ee> <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> <5756DDE6.4090309@delfi.ee> <694BF4B1-49E1-4948-9FC1-BFEDA9CB1305@mac.com> Message-ID: <20160607161836.GA17697@polanet.pl> On Tue, Jun 07, 2016 at 10:48:51 -0400, Jeff Johnson wrote: > Yes the metadata header contains those files. > > Are the files in the payload? > rpm2cpio *.rpm | cpio -itv > > If the files are not in the payload, then they will not be installed. A propos - would it be possible for rpm to support "--verify --package" exactly for this purpose, i.e. verifying metadata/manifest against cpio archive contents (including file checksums) without installing package.rpm? -- Tomasz Pala From glen at delfi.ee Tue Jun 7 18:51:36 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 19:51:36 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <694BF4B1-49E1-4948-9FC1-BFEDA9CB1305@mac.com> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> <57568735.3090302@delfi.ee> <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> <5756DDE6.4090309@delfi.ee> <694BF4B1-49E1-4948-9FC1-BFEDA9CB1305@mac.com> Message-ID: <5756FB98.30204@delfi.ee> On 07.06.2016 17:48, Jeff Johnson wrote: > Sorry for not being precise. > > Yes the metadata header contains those files. > > Are the files in the payload? > rpm2cpio *.rpm | cpio -itv > > If the files are not in the payload, then they will not be installed. yes. present: root at glen 1465233457/1# ls -ld ../*pam**.rpm -rw-r--r-- 1 root root 333764 6. juuni 20:17 ../pam-1.1.8-8.x86_64.rpm -rw-r--r-- 1 root root 35353 6. juuni 20:17 ../pam-libs-1.1.8-8.x86_64.rpm root at glen 1465233457/1# rpm2cpio ../*pam**.rpm | cpio -itv|grep -E '/etc/security/namespace.init|/etc/security/limits.conf|/etc/pam.d/system-auth' -rw-r--r-- 1 root root 1066 Oct 11 2015 ./etc/pam.d/system-auth -rw-r--r-- 1 root root 1824 Feb 25 2015 ./etc/security/limits.conf -rwxr-xr-x 1 root root 1019 Feb 25 2015 ./etc/security/namespace.init 2511 blocks -- glen From qboosh at pld-linux.org Tue Jun 7 19:15:53 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 7 Jun 2016 19:15:53 +0200 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <5755C856.7010101@delfi.ee> References: <5755C856.7010101@delfi.ee> Message-ID: <20160607171553.GA8314@mail> On Mon, Jun 06, 2016 at 10:00:38PM +0300, Elan Ruusam?e wrote: > (pld has --downgrade alias to --oldpackage via popt) > > downgrading from repackage lost config files, > i.e saved them as .rpmsave leaving original path missing > It it the same directory: > # ls -l */*pam* > -rw-r--r-- 1 root root 326K 6. juuni 20:17 > 1465233457/pam-1.1.8-8.x86_64.rpm > -rw-r--r-- 1 root root 35K 6. juuni 20:17 > 1465233457/pam-libs-1.1.8-8.x86_64.rpm as this? > root at glen spool/repackage# > root at glen spool/repackage# rpm -Uhv */*pam* --downgrade (containing only 1.1.8-8)? According to these messages: > warning: package pam = 1:1.1.8-8 was already added, replacing with pam > >= 1:1.2.1-1 > warning: package pam-libs = 1:1.1.8-8 was already added, replacing with > pam-libs >= 1:1.2.1-1 > Preparing... ########################################### [100%] > Repackaging... > 1:pam ########################################### [ 50%] > 2:pam-libs ########################################### [100%] > Upgrading... > 1:pam-libs ########################################### [ 50%] > warning: /etc/security/namespace.init saved as > /etc/security/namespace.init.rpmsave > warning: /etc/security/limits.conf saved as > /etc/security/limits.conf.rpmsave > warning: /etc/pam.d/system-auth saved as /etc/pam.d/system-auth.rpmsave > 2:pam ########################################### [100%] > > root at glen spool/repackage# cd /etc/security/ > root at glen /etc/security# rpm -qf namespace.init > pam-1.2.1-1.x86_64 The "downgraded" pam version is 1.2.1-1, not 1.1.8-8? -- Jakub Bogusz http://qboosh.pl/ From n3npq at me.com Tue Jun 7 19:16:45 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 07 Jun 2016 13:16:45 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <20160607161836.GA17697@polanet.pl> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> <57568735.3090302@delfi.ee> <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> <5756DDE6.4090309@delfi.ee> <694BF4B1-49E1-4948-9FC1-BFEDA9CB1305@mac.com> <20160607161836.GA17697@polanet.pl> Message-ID: <5AEF8654-75B9-4849-9461-3DAFBFD5B83F@me.com> > On Jun 7, 2016, at 12:18 PM, Tomasz Pala wrote: > > On Tue, Jun 07, 2016 at 10:48:51 -0400, Jeff Johnson wrote: > >> Yes the metadata header contains those files. >> >> Are the files in the payload? >> rpm2cpio *.rpm | cpio -itv >> >> If the files are not in the payload, then they will not be installed. > > A propos - would it be possible for rpm to support "--verify --package" > exactly for this purpose, i.e. verifying metadata/manifest against cpio > archive contents (including file checksums) without installing package.rpm? > All rpm operations are supported for any rpm package. The issue with repackaged packages (particularly with %config renaming) is different however. The payload when the repackaged payload is constructed is ?best effort? in the sense that if a file does not exist on its metadata path, then the file cannot be included in the package. Similarly, if a file is modified from the original content, there is no attempt to recalculate file digests, which would also trigger a recalculation of the header SHA1 and (harder) resigning to recreate header-only (and possibly header+payload MD5 and signature, both of which are mostly legacy these days @rpm5.org). The only metadata information in the payload that is used by rpm is the file path, which is used to locate the item in the (signed/digested) header. If the path in the payload is non-existent/modified, then the file will not be installed. There?s likely warnings, certainly when -vv is used, but I would have to look at an actual reproducer to determine what the behavior is with repackaged package downgraded %config files. Meanwhile if the files are in the payload (as reported), then there?s likely a different explanation for why the files are not present after the upgrade/downgrade aren?t present on the file system. In order to do install-before-erase, the file disposition has to be computed for every path so that the erase step does not remove paths that were just upgraded/downgraded. So what I suspect is happening is that the %config file is installed and then removed because the file disposition is not set to ?skipped?. So the next diagnostic step is to repeat the operation(s) with -vv and see what the file disposition is in the remove step, which is displayed after the file path. Note that on upgrade/downgrade, the ?normal? disposition disposition is not displayed to cut down on some of the sewage. So, what is seen on the %config file paths if -vv is added? I predict that the %config files are first installed, but then erased. 73 de Jeff From glen at delfi.ee Tue Jun 7 19:29:05 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 20:29:05 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <5755C856.7010101@delfi.ee> References: <5755C856.7010101@delfi.ee> Message-ID: <57570461.9090502@delfi.ee> On 06.06.2016 22:00, Elan Ruusam?e wrote: > (pld has --downgrade alias to --oldpackage via popt) > > downgrading from repackage lost config files, > i.e saved them as .rpmsave leaving original path missing remote reproducer using docker: (commands that Dockerfile runs are displayed on that page, so not posting them here) https://hub.docker.com/r/glen/rpm-repackage-bug/builds/b96cnokzxisbioj7egrc7d8/ seems to reproduce this and looks like my original problem too, as qboosh pointed out, is that downgrade should match more than one pam package by same name. i will add -vv to commands and ls -l and post the build result in next post to this list. -- glen From glen at delfi.ee Tue Jun 7 19:37:52 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 20:37:52 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <57570461.9090502@delfi.ee> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> Message-ID: <57570670.40607@delfi.ee> On 07.06.2016 20:29, Elan Ruusam?e wrote: > On 06.06.2016 22:00, Elan Ruusam?e wrote: >> (pld has --downgrade alias to --oldpackage via popt) >> >> downgrading from repackage lost config files, >> i.e saved them as .rpmsave leaving original path missing > > remote reproducer using docker: > (commands that Dockerfile runs are displayed on that page, so not > posting them here) > > https://hub.docker.com/r/glen/rpm-repackage-bug/builds/b96cnokzxisbioj7egrc7d8/ > > > seems to reproduce this and looks like my original problem too, as > qboosh pointed out, > is that downgrade should match more than one pam package by same name. > > i will add -vv to commands and ls -l and post the build result in next > post to this list. > here it is: https://hub.docker.com/r/glen/rpm-repackage-bug/builds/btjwvf77j6gvmiu67jpbiek/ -- glen From n3npq at me.com Tue Jun 7 19:42:23 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 07 Jun 2016 13:42:23 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <57570461.9090502@delfi.ee> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> Message-ID: <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> > On Jun 7, 2016, at 1:29 PM, Elan Ruusam?e wrote: > > On 06.06.2016 22:00, Elan Ruusam?e wrote: >> (pld has --downgrade alias to --oldpackage via popt) >> >> downgrading from repackage lost config files, >> i.e saved them as .rpmsave leaving original path missing > > remote reproducer using docker: > (commands that Dockerfile runs are displayed on that page, so not posting them here) > > https://hub.docker.com/r/glen/rpm-repackage-bug/builds/b96cnokzxisbioj7egrc7d8/ > I?m sure the problem is reproducible for you. Meanwhile, if rpm is to support ?downgrade with %config file handling, I need a far simpler reproducer that does not involve docker and hundreds of packages. > seems to reproduce this and looks like my original problem too, as qboosh pointed out, > is that downgrade should match more than one pam package by same name. > There are lots of problems with naming and repackaging, including the very nasty case when a single identical package is repeatedly installed and erased. There will be multiple copies of that package in /var/spool/repackage. (aside) Note that there are ?flink/?blink commands to display the upgrade chains of both installed and erased (i.e. repackaged) packages. Each link in the chain contains 3 items: NVRA MD5 of header+payload SHA1 of header all of which gets even more confusing in the case I described: the transaction id (which is a time stamp) in the /var/spool/directory sub-directory is then needed to disambiguate multiple instances of otherwise identical repackaged packages. > i will add -vv to commands and ls -l and post the build result in next post to this list. > Good. Meanwhile abandoning %config renaming (and doing a git check-in with RPM+LIBGIT2), is likely the best forward-looking solution. There are also better solutions than /var/spool/repackage that can be attempted these days. 73 de Jeff > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From gotar at polanet.pl Tue Jun 7 19:49:20 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 7 Jun 2016 19:49:20 +0200 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <5AEF8654-75B9-4849-9461-3DAFBFD5B83F@me.com> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> <57568735.3090302@delfi.ee> <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> <5756DDE6.4090309@delfi.ee> <694BF4B1-49E1-4948-9FC1-BFEDA9CB1305@mac.com> <20160607161836.GA17697@polanet.pl> <5AEF8654-75B9-4849-9461-3DAFBFD5B83F@me.com> Message-ID: <20160607174920.GA1140@polanet.pl> Note: I'm not referring to %config issue reported, this is only by-the-way question. On Tue, Jun 07, 2016 at 13:16:45 -0400, Jeffrey Johnson wrote: >> A propos - would it be possible for rpm to support "--verify --package" >> exactly for this purpose, i.e. verifying metadata/manifest against cpio >> archive contents (including file checksums) without installing package.rpm? > > All rpm operations are supported for any rpm package. But --verify checks against filesystem. I'm looking for a way to check against cpio inside... > is different however. The payload when the repackaged payload is constructed > is ???best effort??? in the sense that if a file does not exist on its metadata path, then > the file cannot be included in the package. Similarly, if a file is modified > from the original content, there is no attempt to recalculate file digests, which > would also trigger a recalculation of the header SHA1 and (harder) resigning [...] ...just for such cases as you described. In other words: I want to check if repackaged.rpm contains changed files. Let's name it: integrity test (manifest vs cpio). Currently I'm able to do it by installing such package in newly created (empty) root and verifying against files put inside, but there should be more elegant/effective way. Considering the --install checks digests (thus --nomd5/--nodigest was required to install repackaged.rpms with modified contents), it should be enough to skip appropriate code path, the one that actually commits filesystem changes. -- Tomasz Pala From n3npq at me.com Tue Jun 7 19:55:50 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 07 Jun 2016 13:55:50 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <20160607174920.GA1140@polanet.pl> References: <5755C856.7010101@delfi.ee> <6ED99714-846A-4780-9C77-329BBF7BDE13@me.com> <20160607030433.GA22086@polanet.pl> <32462926-53FE-494A-BD3E-622D593FCE4E@me.com> <57568735.3090302@delfi.ee> <994D3F93-6522-489A-8648-BAB55E32CD9C@me.com> <5756DDE6.4090309@delfi.ee> <694BF4B1-49E1-4948-9FC1-BFEDA9CB1305@mac.com> <20160607161836.GA17697@polanet.pl> <5AEF8654-75B9-4849-9461-3DAFBFD5B83F@me.com> <20160607174920.GA1140@polanet.pl> Message-ID: > On Jun 7, 2016, at 1:49 PM, Tomasz Pala wrote: > > Note: I'm not referring to %config issue reported, this is only by-the-way question. > > On Tue, Jun 07, 2016 at 13:16:45 -0400, Jeffrey Johnson wrote: > >>> A propos - would it be possible for rpm to support "--verify --package" >>> exactly for this purpose, i.e. verifying metadata/manifest against cpio >>> archive contents (including file checksums) without installing package.rpm? >> >> All rpm operations are supported for any rpm package. > > But --verify checks against filesystem. I'm looking for a way to check > against cpio inside? > OK. >> is different however. The payload when the repackaged payload is constructed >> is ???best effort??? in the sense that if a file does not exist on its metadata path, then >> the file cannot be included in the package. Similarly, if a file is modified >> from the original content, there is no attempt to recalculate file digests, which >> would also trigger a recalculation of the header SHA1 and (harder) resigning > [...] > > ...just for such cases as you described. In other words: I want to check > if repackaged.rpm contains changed files. Let's name it: integrity test > (manifest vs cpio). > > Currently I'm able to do it by installing such package in newly created > (empty) root and verifying against files put inside, but there should be > more elegant/effective way. Considering the --install checks digests > (thus --nomd5/--nodigest was required to install repackaged.rpms with > modified contents), it should be enough to skip appropriate code path, > the one that actually commits filesystem changes. > If you diff rpm -qplv and rpm2cpio ? | cpio-itv spewage, you will verify that all the cpio headers are identical to what is in metadata. Those 2 outputs were identical at one point in time, but the sewage display conventions for rpm/cpio might have changed since implemented. 73 de Jeff From glen at delfi.ee Tue Jun 7 19:58:10 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 20:58:10 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> Message-ID: <57570B32.3040202@delfi.ee> On 07.06.2016 20:42, Jeffrey Johnson wrote: >> On Jun 7, 2016, at 1:29 PM, Elan Ruusam?e wrote: >> >> On 06.06.2016 22:00, Elan Ruusam?e wrote: >>> (pld has --downgrade alias to --oldpackage via popt) >>> >>> downgrading from repackage lost config files, >>> i.e saved them as .rpmsave leaving original path missing >> remote reproducer using docker: >> (commands that Dockerfile runs are displayed on that page, so not posting them here) >> >> https://hub.docker.com/r/glen/rpm-repackage-bug/builds/b96cnokzxisbioj7egrc7d8/ >> > I?m sure the problem is reproducible for you. Meanwhile, if rpm is to support > ?downgrade with %config file handling, I need a far simpler reproducer > that does not involve docker and hundreds of packages. > docker was just easy way to show how problem can be reproduced. nothing suits you. a reproducer that you can run on your own however you want. and docker runs nowadays linux/osx/windows, natively! [*1] to preproduce just need two packages: 1. old package, v1.1 2. new package, v1.2 and scenario: 1. install v1.1 2. upgrade v1.1->v1.2 3. "downgrade" v1.2->v1.1 with matching v1.1 and v1.2 packages (it will not really downgrade) showing this, using the same docker image: 1. download "pure" packages: # poldek --fetch=/tmp -u pam pam-libs --nodeps # poldek --fetch=/tmp -u pam pam-libs --force -n th-2015 --noask bash-4.3# ls -l /tmp/*pam* -rw-r--r-- 1 root root 747324 Mar 28 2015 /tmp/pam-1.1.8-8.x86_64.rpm -rw-r--r-- 1 root root 760576 May 15 08:41 /tmp/pam-1.2.1-1.x86_64.rpm -rw-r--r-- 1 root root 34016 Mar 28 2015 /tmp/pam-libs-1.1.8-8.x86_64.rpm -rw-r--r-- 1 root root 34391 May 15 08:41 /tmp/pam-libs-1.2.1-1.x86_64.rpm bash-4.3# rpm -q pam pam-libs pam-1.2.1-1.x86_64 pam-libs-1.2.1-1.x86_64 bash-4.3# rpm -Uhv --oldpackage /tmp/*pam* warning: package pam = 1:1.1.8-8 was already added, replacing with pam >= 1:1.2.1-1 warning: package pam-libs = 1:1.1.8-8 was already added, replacing with pam-libs >= 1:1.2.1-1 Preparing... ########################################### [100%] Repackaging... 1:pam ########################################### [ 50%] 2:pam-libs ########################################### [100%] Upgrading... 1:pam-libs ########################################### [ 50%] warning: /etc/environment saved as /etc/environment.rpmsave 2:pam ########################################### [100%] bash-4.3# rpm -q pam pam-libs pam-1.2.1-1.x86_64 pam-libs-1.2.1-1.x86_64 bash-4.3# > Meanwhile abandoning %config renaming (and doing a git check-in with RPM+LIBGIT2), > is likely the best forward-looking solution. pld will not sign up to this. %config handling needs to be fixed. > There are also better solutions than /var/spool/repackage that can be attempted these > days. why are you sure it's repackage problem if you can't even understand why it behaves like it does. i've seen rpm losing configs ever other corner. this was just easily reproducible usecase. [*1]: may need beta signup, i'm not using win/mac myself -- glen From n3npq at me.com Tue Jun 7 20:04:35 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 07 Jun 2016 14:04:35 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <57570670.40607@delfi.ee> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <57570670.40607@delfi.ee> Message-ID: <8D276E37-9151-4645-9EA8-5B92DE732ABE@me.com> > On Jun 7, 2016, at 1:37 PM, Elan Ruusam?e wrote: > > > here it is: > https://hub.docker.com/r/glen/rpm-repackage-bug/builds/btjwvf77j6gvmiu67jpbiek/ > OK. (aside) If you take out the -h progress bar, the -vv file is easier to read. The spewage contains pam warning: /etc/security/limits.conf created as /etc/security/limits.conf.rpmnew warning: /etc/security/namespace.init created as /etc/security/namespace.init.rpmnew So the install did not install, the remove renamed the existing modified files with .rpmsave (AFAICT). ATM, it?s not at all clear how to unsnarl %config handling (which will clobber existing renamed files). But perhaps something can be done. Again, my personal belief is that changing/fixing %config handling in RPM, particularly with ?downgrade and repackaging, cannot ever solve the problem of removed files, or external intervention to rename files. RPM+LIBGIT2 is a far better way forward. 73 de Jeff From gotar at polanet.pl Tue Jun 7 20:07:31 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 7 Jun 2016 20:07:31 +0200 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> Message-ID: <20160607180731.GB1140@polanet.pl> On Tue, Jun 07, 2016 at 13:42:23 -0400, Jeffrey Johnson wrote: > There are also better solutions than /var/spool/repackage that can be attempted these > days. What are they? Filesystem-level snapshots are not suitable when you need to revert anything older than a few hours maybe (can anyone afford restoring 2 weeks old state and replaying every other change that was made meanwhile?), so what else? And if not for --rollback, repackages are great for cherry-picking single package do downgrade. -- Tomasz Pala From n3npq at me.com Tue Jun 7 20:18:20 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 07 Jun 2016 14:18:20 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <57570B32.3040202@delfi.ee> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <57570B32.3040202@delfi.ee> Message-ID: <17C8310B-A13E-4F29-8CE7-90F1911B4E4C@me.com> > On Jun 7, 2016, at 1:58 PM, Elan Ruusam?e wrote: > > >> Meanwhile abandoning %config renaming (and doing a git check-in with RPM+LIBGIT2), >> is likely the best forward-looking solution. > pld will not sign up to this. %config handling needs to be fixed. Then PLD has its solution ? Patches cheerfully accepted at >> There are also better solutions than /var/spool/repackage that can be attempted these >> days. > why are you sure it's repackage problem if you can't even understand why it behaves like it does. > i've seen rpm losing configs ever other corner. this was just easily reproducible use case. I?m not sure of anything I cannot reproduce by ?make test? when developing RPM, there are far too many issues that have to be controlled for. Note that ?downgrade (even as a popt alias for ?old package) has never been supported (or tested) by rpm. Sure you can add ?oldpackage (or any other disabler) as you wish, but you are also responsible for the effects of, say, adding ?replace files (which will clobber %config every single time, exactly by design). I cannot use a docker environment under ?make test? while developing is all that I intended to say. And to support ?downgrade meaningfully, I need a ?reproducible? test case with toy packages. Meanwhile, for less effort, I believe that doing RPM+LIBGIT2 is far more beneficial than trying to resurrect and modernize %config renaming: there are too many problems with renaming and manual intervention to ?fix? an installation after running rpm (as you have reported many many times). > [*1]: may need beta signup, i'm not using win/mac myself > > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From glen at delfi.ee Tue Jun 7 20:20:28 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 21:20:28 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <8D276E37-9151-4645-9EA8-5B92DE732ABE@me.com> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <57570670.40607@delfi.ee> <8D276E37-9151-4645-9EA8-5B92DE732ABE@me.com> Message-ID: <5757106C.4030801@delfi.ee> On 07.06.2016 21:04, Jeffrey Johnson wrote: > The spewage contains > > pam warning: /etc/security/limits.conf created as /etc/security/limits.conf.rpmnew > warning: /etc/security/namespace.init created as /etc/security/namespace.init.rpmnew > > So the install did not install, the remove renamed the existing > modified files with .rpmsave (AFAICT). you should not look at the commands that created scenario (but they may be useful to understand how to reproducer) the reproducer starts from last command: Step 8 : RUN rpm -Uhv --downgrade /var/spool/repackage/*/pam*.rpm -vv -- glen From glen at pld-linux.org Tue Jun 7 20:21:35 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 21:21:35 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <20160607180731.GB1140@polanet.pl> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <20160607180731.GB1140@polanet.pl> Message-ID: <575710AF.10301@pld-linux.org> On 07.06.2016 21:07, Tomasz Pala wrote: > On Tue, Jun 07, 2016 at 13:42:23 -0400, Jeffrey Johnson wrote: > >> >There are also better solutions than /var/spool/repackage that can be attempted these >> >days. > What are they? docker is one ;) -- glen From n3npq at me.com Tue Jun 7 20:26:46 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 07 Jun 2016 14:26:46 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <575710AF.10301@pld-linux.org> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <20160607180731.GB1140@polanet.pl> <575710AF.10301@pld-linux.org> Message-ID: > On Jun 7, 2016, at 2:21 PM, Elan Ruusam?e wrote: > > On 07.06.2016 21:07, Tomasz Pala wrote: >> On Tue, Jun 07, 2016 at 13:42:23 -0400, Jeffrey Johnson wrote: >> >>> >There are also better solutions than /var/spool/repackage that can be attempted these >>> >days. >> What are they? > > docker is one ;) > Many (if not most) docker images start from *.rpm content fiddled up through many means. docker is useless without images constructed (as a starting point) from packages. comparing docker to package management misses the point: the two tools solve very different problems. 73 de Jeff > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From glen at pld-linux.org Tue Jun 7 20:27:12 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 21:27:12 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <17C8310B-A13E-4F29-8CE7-90F1911B4E4C@me.com> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <57570B32.3040202@delfi.ee> <17C8310B-A13E-4F29-8CE7-90F1911B4E4C@me.com> Message-ID: <57571200.2090106@pld-linux.org> On 07.06.2016 21:18, Jeffrey Johnson wrote: > Patches cheerfully accepted at seen how you bashed proyvind when he submitted his patches to the list! 40% of pld patches originate from him. do not want to go that path! -- glen From n3npq at me.com Tue Jun 7 20:29:24 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 07 Jun 2016 14:29:24 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <20160607180731.GB1140@polanet.pl> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <20160607180731.GB1140@polanet.pl> Message-ID: <6A1D059D-727A-45DF-9D44-5024562A5B05@me.com> > On Jun 7, 2016, at 2:07 PM, Tomasz Pala wrote: > > On Tue, Jun 07, 2016 at 13:42:23 -0400, Jeffrey Johnson wrote: > >> There are also better solutions than /var/spool/repackage that can be attempted these >> days. > > What are they? Filesystem-level snapshots are not suitable when you need > to revert anything older than a few hours maybe (can anyone afford > restoring 2 weeks old state and replaying every other change that was > made meanwhile?), so what else? > > And if not for --rollback, repackages are great for cherry-picking > single package do downgrade. > is not the place for RPM development discussions. This thread is/was diagnosing a problem and devising a solution, not otherwise. See Poky/Yocto image construction for what RPM5 can already do when used intelligently. 73 de Jeff From glen at pld-linux.org Tue Jun 7 20:30:32 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 21:30:32 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <20160607180731.GB1140@polanet.pl> <575710AF.10301@pld-linux.org> Message-ID: <575712C8.2010603@pld-linux.org> On 07.06.2016 21:26, Jeffrey Johnson wrote: >> >On Jun 7, 2016, at 2:21 PM, Elan Ruusam?e wrote: >> > >> >On 07.06.2016 21:07, Tomasz Pala wrote: >>> >>On Tue, Jun 07, 2016 at 13:42:23 -0400, Jeffrey Johnson wrote: >>> >> >>>>> >>> >There are also better solutions than /var/spool/repackage that can be attempted these >>>>> >>> >days. >>> >>What are they? >> > >> >docker is one;) >> > > Many (if not most) docker images start from *.rpm content fiddled up > through many means. > > docker is useless without images constructed (as a starting point) from packages. > > comparing docker to package management misses the point: the two tools > solve very different problems. point was that using docker, you will not need repackage, you just use previous docker image -- glen From n3npq at me.com Tue Jun 7 20:31:56 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 07 Jun 2016 14:31:56 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <57571200.2090106@pld-linux.org> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <57570B32.3040202@delfi.ee> <17C8310B-A13E-4F29-8CE7-90F1911B4E4C@me.com> <57571200.2090106@pld-linux.org> Message-ID: > On Jun 7, 2016, at 2:27 PM, Elan Ruusam?e wrote: > > On 07.06.2016 21:18, Jeffrey Johnson wrote: >> Patches cheerfully accepted at > > seen how you bashed proyvind when he submitted his patches to the list! > 40% of pld patches originate from him. > > do not want to go that path! > OK, I?ve had enuf here. You reported an rpm problem, I?ve tried to help. Next time you can wait for proyvind to give you a patch to solve whatever rpm problem you report, if that is what you prefer. 73 de Jeff > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From glen at pld-linux.org Tue Jun 7 20:42:47 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 21:42:47 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <17C8310B-A13E-4F29-8CE7-90F1911B4E4C@me.com> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <57570B32.3040202@delfi.ee> <17C8310B-A13E-4F29-8CE7-90F1911B4E4C@me.com> Message-ID: <575715A7.6060600@pld-linux.org> On 07.06.2016 21:18, Jeffrey Johnson wrote: > And to support ?downgrade meaningfully, I need a ?reproducible? test case with toy packages. the toy packages: http://carme.pld-linux.org/~glen/rpm-repackage-bug-pam-files.tar.xz 1,4M contents obtained with: $ docker run -it -v `pwd`:/tmp --rm glen/pld poldek --fetch=/tmp -u pam pam-libs --noask --force $ docker run -it -v `pwd`:/tmp --rm glen/pld poldek --fetch=/tmp -u pam pam-libs --noask --force -n th-2015 however you can (to my understanding) create the packages yourself: 1. create package v1.1 having %config(noreplace) %verify(not md5 mtime size) 2. create package v1.2 having %config(noreplace) %verify(not md5 mtime size) reproduce: 1. install package v1.2 2. install packages v1.1 and v1.2 with rpm -Uv --oldpackage between 1-2 may need to alter the config file, but afaik not neccessary -- glen From glen at pld-linux.org Tue Jun 7 20:49:36 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 7 Jun 2016 21:49:36 +0300 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <57570B32.3040202@delfi.ee> <17C8310B-A13E-4F29-8CE7-90F1911B4E4C@me.com> <57571200.2090106@pld-linux.org> Message-ID: <57571740.4040809@pld-linux.org> On 07.06.2016 21:31, Jeffrey Johnson wrote: > Next time you can wait for proyvind to give you a patch to > solve whatever rpm problem you report, if that is what you prefer. no i prefer rpm5 modernized it's contribution system, submitting patches to mailing list is so 90s. it should have github/gitlab-like system where patch can be submitted as Pull-Request/Merge-Request and appropriate discussion be in that specific thread. also pld has dozen of patches collected from the internet which can't be submitted by pld dudes because they have not enough knowledge to validate the patch reasoning and provide test cases. the patches just work for us. why they never landed in rpm5 repo, you already know. also, proyvind did not write patches for pld, pld just took his patches what he had in rpm5 submit queue. -- glen From n3npq at me.com Wed Jun 8 00:04:33 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 07 Jun 2016 18:04:33 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <57571740.4040809@pld-linux.org> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <57570B32.3040202@delfi.ee> <17C8310B-A13E-4F29-8CE7-90F1911B4E4C@me.com> <57571200.2090106@pld-linux.org> <57571740.4040809@pld-linux.org> Message-ID: <88C950A1-CB8D-4806-ACAD-117C449C94C8@me.com> Sent from my iPad > On Jun 7, 2016, at 2:49 PM, Elan Ruusam?e wrote: > >> On 07.06.2016 21:31, Jeffrey Johnson wrote: >> Next time you can wait for proyvind to give you a patch to >> solve whatever rpm problem you report, if that is what you prefer. > no i prefer rpm5 modernized it's contribution system, submitting patches to mailing list is so 90s. > Um I need notification somehow of what you wish integrated upstream. > it should have github/gitlab-like system where patch can be submitted as Pull-Request/Merge-Request and appropriate discussion be in that specific thread. > The @rpm5.org project uses CVS still largely because of lack of resources. (aside) I spent a week converting the entire @rpm5.org cvs repository to git last year at git.rpm.org. There has been exactly zero interest in accessing, too little interest to even contemplate switching the repository into "production" every day use imho. > also pld has dozen of patches collected from the internet which can't be submitted by pld dudes because they have not enough knowledge to validate the patch reasoning and provide test cases. the patches just work for us. why they never landed in rpm5 repo, you already know. > (aside) Having vetted proyvind's patches (some of which I wrote) multiple times, I asked for exactly what you lack: what problem does the patch solve? what is the usage case? proyvind was given the choice between launchpad.org (with equivalent to git issues to discuss patches) or e-mail, he chose e-mail with a 1-line comment. There is a public record including my comments so that I don't have to review all this crap for the 5th or 10th time. I am not the impediment to moderrn github/gitlab merges is the point, particularly when issues from 5y ago are explicitly stated as a reason to not submit. For the record: I vet PLD patches every 9 months or so and integrate the patches that seem useful. I have been doing that for more than a decade. > also, proyvind did not write patches for pld, pld just took his patches what he had in rpm5 submit queue. > There is no "submit queue" ... every proyvind patch that was submitted has been responded too. Every patch that looked useful was merged, rejected patches were responded with comments, both private and public. I'm way tired of *driva distro politics from 5+ years ago. FYI: I am the current rpm package maintainer in OpenMandriva since being asked to help maintain a critical piece of infrastructure through the controversies that follow proyvind everywhere he goes ... Meanwhile, thanks for cooking down your %config issue to toy packages that might fit into a test harness. And if you have patches for (that I have missed or not gotten to or that you think should be upstream etc) then you kinda need to tell me before complaining. Off to look at the reproducer next few days ... 73 de Jeff > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From n3npq at me.com Wed Jun 8 00:27:38 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 07 Jun 2016 18:27:38 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <88C950A1-CB8D-4806-ACAD-117C449C94C8@me.com> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <57570B32.3040202@delfi.ee> <17C8310B-A13E-4F29-8CE7-90F1911B4E4C@me.com> <57571200.2090106@pld-linux.org> <57571740.4040809@pld-linux.org> <88C950A1-CB8D-4806-ACAD-117C449C94C8@me.com> Message-ID: ... git.rpm5.org ... *shrug* no idea how to do cut'n'paste reliably on an iPad. 73 de Jeff Sent from my iPad > On Jun 7, 2016, at 6:04 PM, Jeffrey Johnson wrote: > > > > Sent from my iPad > >>> On Jun 7, 2016, at 2:49 PM, Elan Ruusam?e wrote: >>> >>> On 07.06.2016 21:31, Jeffrey Johnson wrote: >>> Next time you can wait for proyvind to give you a patch to >>> solve whatever rpm problem you report, if that is what you prefer. >> no i prefer rpm5 modernized it's contribution system, submitting patches to mailing list is so 90s. > > Um I need notification somehow of what you wish integrated upstream. > >> it should have github/gitlab-like system where patch can be submitted as Pull-Request/Merge-Request and appropriate discussion be in that specific thread. > > The @rpm5.org project uses CVS still largely because of lack of resources. > > (aside) > I spent a week converting the entire @rpm5.org cvs repository to git > last year at git.rpm.org. There has been exactly zero interest in accessing, > too little interest to even contemplate switching the repository into > "production" every day use imho. > >> also pld has dozen of patches collected from the internet which can't be submitted by pld dudes because they have not enough knowledge to validate the patch reasoning and provide test cases. the patches just work for us. why they never landed in rpm5 repo, you already know. > > (aside) > Having vetted proyvind's patches (some of which I wrote) multiple times, I asked for exactly what you lack: > what problem does the patch solve? > what is the usage case? > proyvind was given the choice between launchpad.org (with equivalent to git issues > to discuss patches) or e-mail, he chose e-mail with a 1-line > comment. > > There is a public record including my comments so that I don't have to review > all this crap for the 5th or 10th time. > > I am not the impediment to moderrn github/gitlab merges is the point, > particularly when issues from 5y ago are explicitly stated as a reason > to not submit. > > For the record: I vet PLD patches every 9 months or so and integrate > the patches that seem useful. I have been doing that for more than a decade. > >> also, proyvind did not write patches for pld, pld just took his patches what he had in rpm5 submit queue. > > There is no "submit queue" ... every proyvind patch that was submitted > has been responded too. Every patch that looked useful was merged, rejected > patches were responded with comments, both private and public. > > I'm way tired of *driva distro politics from 5+ years ago. > > FYI: I am the current rpm package maintainer in OpenMandriva since being > asked to help maintain a critical piece of infrastructure through the controversies that follow proyvind everywhere he goes ... > > Meanwhile, thanks for cooking down your %config issue to toy packages > that might fit into a test harness. > > And if you have patches for (that I have missed or not gotten to or that you think > should be upstream etc) then you kinda need to tell me before complaining. > > Off to look at the reproducer next few days ... > > 73 de Jeff >> -- >> glen >> >> _______________________________________________ >> pld-devel-en mailing list >> pld-devel-en at lists.pld-linux.org >> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From gotar at polanet.pl Wed Jun 8 04:57:29 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 8 Jun 2016 04:57:29 +0200 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <6A1D059D-727A-45DF-9D44-5024562A5B05@me.com> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <20160607180731.GB1140@polanet.pl> <6A1D059D-727A-45DF-9D44-5024562A5B05@me.com> Message-ID: <20160608025729.GA1989@polanet.pl> On Tue, Jun 07, 2016 at 14:29:24 -0400, Jeffrey Johnson wrote: >>> There are also better solutions than /var/spool/repackage that can be attempted these >>> days. >> >> What are they? Filesystem-level snapshots are not suitable when you need >> to revert anything older than a few hours maybe (can anyone afford >> restoring 2 weeks old state and replaying every other change that was >> made meanwhile?), so what else? >> >> And if not for --rollback, repackages are great for cherry-picking >> single package do downgrade. http://lists.rpm.org/pipermail/rpm-maint/2008-February/001911.html FS-level snapshots are shortest way to 'reboot to upgrade' insanity. > is not the place for RPM development discussions. It's you who are doing some obsolescence suggestions, just don't do that if you have nothing clear as a replacement or going to make it secret. > This thread is/was diagnosing a problem and devising a solution, not otherwise. Different approach to entire repackage (that YOU suggested) is also a solution. The only alternative I know: https://www.redhat.com/archives/rhelv6-beta-list/2010-June/msg00056.html yum-history, is not suitable for PLD due to rolling releases - package I had might be not available for download anymore. yum-plugin-fs-snapshot is a no-go on any non-desktop or non-singleuser machine. That leaves us with not a single 'better solutions these days'. I remember you wrote about libgit a few years ago, but that might handle %config problems only, but not restoring packages to some previous (working) state. > See Poky/Yocto image construction for what RPM5 can already do when > used intelligently. I doubt embedded platform uses rpm5 to solve issues like "there is a problem with foo using libbar we have upgraded last week, need to restore previous versions and do some more tests on separate/clean environment". So unless you are willing to share the mysterious features that might be used instead repackages, I'm not going to waste my time digging in system build with different principles in mind and for entirely different purpose than PLD. That's great, if rpm5 solves their problems - can it solve ours? If so, just tell us how. No need for elaborates. OK, I know one solution: fetching rpms via permanent-store proxy like wwwoffle and keeping those rpms forever, as there is no way to implement "keep THAT time since package was upgraded" policy. Repackages are superior in two ways: 1. they are timestamped on upgrade, so one could remove old ones, 2. they retain current configuration within. -- Tomasz Pala From gotar at polanet.pl Wed Jun 8 05:12:16 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 8 Jun 2016 05:12:16 +0200 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <575710AF.10301@pld-linux.org> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <20160607180731.GB1140@polanet.pl> <575710AF.10301@pld-linux.org> Message-ID: <20160608031216.GA19666@polanet.pl> On Tue, Jun 07, 2016 at 21:21:35 +0300, Elan Ruusam?e wrote: >>> >There are also better solutions than /var/spool/repackage that can be attempted these >>> >days. >> What are they? > > docker is one ;) How? Recently I've upgraded foo and after two weeks some problem emerged. How exactly is docker going to help me restoring system to working state? Have in mind problem definition: "upgrade went fine, but has broken something - one noticed that some time later". Last time I had something like this was on Ubuntu machine, which frozen after reboot. I dug in /var/cache/apt/archives and found that the kernel itself was upgraded a week before, fortunately the previous one was still installed. If it hadn't and if some would have purged apt cache before, I'd stuck. -- Tomasz Pala From n3npq at me.com Wed Jun 8 06:10:36 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Wed, 08 Jun 2016 00:10:36 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <20160608025729.GA1989@polanet.pl> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <20160607180731.GB1140@polanet.pl> <6A1D059D-727A-45DF-9D44-5024562A5B05@me.com> <20160608025729.GA1989@polanet.pl> Message-ID: <883791A9-6028-4CBA-A772-9DAD0BD34568@me.com> > On Jun 7, 2016, at 10:57 PM, Tomasz Pala wrote: > > On Tue, Jun 07, 2016 at 14:29:24 -0400, Jeffrey Johnson wrote: > >>>> There are also better solutions than /var/spool/repackage that can be attempted these >>>> days. >>> >>> What are they? Filesystem-level snapshots are not suitable when you need >>> to revert anything older than a few hours maybe (can anyone afford >>> restoring 2 weeks old state and replaying every other change that was >>> made meanwhile?), so what else? >>> >>> And if not for --rollback, repackages are great for cherry-picking >>> single package do downgrade. > > http://lists.rpm.org/pipermail/rpm-maint/2008-February/001911.html > OK, I?ll bite: you quote James Antill from 8 years ago ? what are you trying to say? Please ? > FS-level snapshots are shortest way to 'reboot to upgrade' insanity. > So you seem to not like ?FS snapshots? ? Good, I think FS snapshots have little to do with ?rollback too, we may possibly agree. FS snapshots have a usage case, but not with ?rollback for package management. >> is not the place for RPM development discussions. > > It's you who are doing some obsolescence suggestions, just don't do that > if you have nothing clear as a replacement or going to make it secret. > Obsolesence? Hardly ? there are some serious flaws in RPM in need of repair 20+ years later ? including %config handling, the start of this thread. (aside) I do have some serious credentials having 18+ years experience with RPM, and also having implemented 2-3 ?rollback schemes in RPM, mostly useless for other reasons. You could (but apparently the EU funded Mancoosi task force 3 on transactional package management mail archives are no longer available, oh well) read the history of what has transpired this century, certainly more details since James Antill posted in 2008, if really interested ? ? but go ahead and claim vaporware or accuse me of keeping my ideas ?secret? (or worse, not able to backup my claims with an implementation) if you insist. All I meant to suggest is that the PLD devel list is _NOT_ the pace to discuss RPM package management issues (including repackaging, and ?rollback) seriously. >> This thread is/was diagnosing a problem and devising a solution, not otherwise. > > Different approach to entire repackage (that YOU suggested) is also a solution. > What are you trying to say here? Do you like/want repackaging or not? I did successfully implement repackaging (what is currently used by PLD) while @redhat in like 2003 or so. I?m happy you like what I implemented, but damfino what you wish changed. > The only alternative I know: > https://www.redhat.com/archives/rhelv6-beta-list/2010-June/msg00056.html > yum-history, is not suitable for PLD due to rolling releases - package I > had might be not available for download anymore. yum-plugin-fs-snapshot > is a no-go on any non-desktop or non-singleuser machine. That leaves us > with not a single 'better solutions these days?. Um, a yum-history citation, and from 2010? which depends on what is called a ?yumdb? ? is mostly useless, perhaps more useless than FS snapshots that you seem to dislike. JMHO, YMMV. We can explore details as you wish ... The very serious flaw(s) with a yumdb are: 1) any value (like a nominal ~128b string containing package NEVRA) uses an entire (usually 4Kb) block on a FS. That is 4096 - 128 = 3968b of wasted disk space. 2) there is no means to truncate yumdb file system usage, a yumdb is forever (well, you can just nuke the entire FS tree whenever you want to regain FS space for other uses) I can/will enumerate several additional flaws if absolutely necessary. We seem to agree that yum-history is not appropriate for PLD (and more generally, rather a waste of disk space). > I remember you wrote about libgit a few years ago, but that might handle > %config problems only, but not restoring packages to some previous > (working) state. > You?ll have to remind me of what I wrote, I have written lots about RPM over the years ? >> See Poky/Yocto image construction for what RPM5 can already do when >> used intelligently. > > I doubt embedded platform uses rpm5 to solve issues like "there is a > problem with foo using libbar we have upgraded last week, need to > restore previous versions and do some more tests on separate/clean > environment". So unless you are willing to share the mysterious features > that might be used instead repackages, I'm not going to waste my time > digging in system build with different principles in mind and for entirely > different purpose than PLD. That's great, if rpm5 solves their problems > - can it solve ours? If so, just tell us how. No need for elaborates. > You need to study before responding: Poky/Yocto install images are produced by cross-compilation on standard *x86 blade hardware, nothing whatsoever to do with ?embedded?, and (perhaps) very little to do with ?repackaging?. I mentioned P/Y largely because of what is called a ?solvedb?, which is little more than an rpmdb with a URL pointer to the original (or copy) *.rpm package, which solves the problem of removed/erased files that repackaging will never be able to solve correctly. Meanwhile, , not , is the proper forum for discussion of RPM. That is all that I said. > OK, I know one solution: fetching rpms via permanent-store proxy like > wwwoffle and keeping those rpms forever, as there is no way to implement > "keep THAT time since package was upgraded" policy. Repackages are > superior in two ways: > 1. they are timestamped on upgrade, so one could remove old ones, > 2. they retain current configuration within. > Once you remove ?old ones? (presumably ones == packages), you risk a loss of referential integrity. We might (but unclear) even agree on this point. I know of at least 3 linux distros (including @redhat.com) that have independently discovered that you MUST keep a permanent record of all published packages in order to do ?upgrades? ? or possibly ?downgrades? ? reliably. (aside) Please don?t take my comments personally: I?ll be happy to discuss better RPM implementations as you wish in an appropriate forum related to RPM, not PLD. 73 de Jeff From glen at delfi.ee Wed Jun 8 08:04:28 2016 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 8 Jun 2016 09:04:28 +0300 Subject: rpm5 (Re: rpm -Uhv --oldpackage loses configs) In-Reply-To: <88C950A1-CB8D-4806-ACAD-117C449C94C8@me.com> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <57570B32.3040202@delfi.ee> <17C8310B-A13E-4F29-8CE7-90F1911B4E4C@me.com> <57571200.2090106@pld-linux.org> <57571740.4040809@pld-linux.org> <88C950A1-CB8D-4806-ACAD-117C449C94C8@me.com> Message-ID: <5757B56C.1030906@delfi.ee> On 08.06.2016 01:04, Jeffrey Johnson wrote: > (aside) > I spent a week converting the entire @rpm5.org cvs repository to git > last year at git.rpm.org. There has been exactly zero interest in accessing, > too little interest to even contemplate switching the repository into > "production" every day use imho. and how exactly one should know it should be accessed? there's no "news" on frontpage, http://rpm5.org/ says that Production version of RPM is 5.3.6 clicking "sources" link http://rpm5.org/sources.php gives just cvs info roadmap http://rpm5.org/roadmap.php speaks about 2007 last news item is from 2008 http://rpm5.org/news.php or is it 2009? why it's under 2008? there's no "blog" either announcing cool and fun stuff that some active projects do the only way to even know about cvs->git, is to subscribe to mailinglist, again so 1990s. i personally won't do that, it's too much noise to be subscribed to mailinglists. oh, and git.rpm5.org gives centos standard page, so can't even clone the repo to see it's conversion quality. ps: you could also write "blog" (mailinglist post in your case) of your cvs2git progress, would be fun to read how you did it, problems encountered, how solved, as i understand rpm5 cvs repo was quite unique, i haven't seen 2.x cvs revisions anywhere else. and also i think i've made at least 1 commit to rpm5 cvs repo. i was never contacted to be asked what i wish my author email to be, that is not nice. -- glen From adwol at zonk.pl Wed Jun 8 11:53:04 2016 From: adwol at zonk.pl (Adam Osuchowski) Date: Wed, 8 Jun 2016 11:53:04 +0200 Subject: [packages/GeoIP-db-IPASNum] updated to 2016.06.06 In-Reply-To: References: <2b32b421191f339f1045ff94b9fbc89b0e65bcd5_refs_heads_master@pld-linux.org> Message-ID: <20160608095304.6b8b4567@zonk.pl> glen wrote: > commit dbd877a6d696b54bd4ba3feb7a7c62034235792d > Author: Elan Ruusam?e > Date: Wed Jun 8 01:04:09 2016 +0300 > > updated to 2016.06.06 > > GeoIP-db-IPASNum.spec | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > --- > diff --git a/GeoIP-db-IPASNum.spec b/GeoIP-db-IPASNum.spec > index e6b2ec6..047716a 100644 > --- a/GeoIP-db-IPASNum.spec > +++ b/GeoIP-db-IPASNum.spec > @@ -2,12 +2,12 @@ Summary: GeoLite IPASNum - IP to AS number translation database for GeoIP > Summary(pl.UTF-8): GeoLite IPASNum - baza danych t?umacze? adres?w IP na numery AS dla GeoIP > Name: GeoIP-db-IPASNum > # Updated every month: > -Version: 2016.06.07 > +Version: 2016.06.06 > Release: 1 > License: CC 3.0 BY-SA > Group: Applications/Databases > Source0: http://download.maxmind.com/download/geoip/database/asnum/GeoIPASNum.dat.gz?/GeoIPASNum-%{version}.dat.gz > -# Source0-md5: 0a384c96479df8616116da9f12bcd471 > +# Source0-md5: 2c31a48670d00dde926587ec0ccff964 Could you explain where did you get this source from and why did you commit older version? builder at pld:~/rpm/packages$ builder -g -nd GeoIP-db-IPASNum Cloning into 'GeoIP-db-IPASNum'... remote: Counting objects: 379, done. remote: Compressing objects: 100% (237/237), done. remote: Total 379 (delta 139), reused 53 (delta 32) Receiving objects: 100% (379/379), 40.21 KiB | 0 bytes/s, done. Resolving deltas: 100% (139/139), done. Checking connectivity... done. remote: Counting objects: 3, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. >From git://git.pld-linux.org/packages/GeoIP-db-IPASNum * [new ref] refs/notes/commits -> refs/notes/commits MD5 sum mismatch. Use -U to refetch sources, or -5 to update md5 sums, if you're sure files are correct. Error: some source, patch or icon files not stored in PLD repo. (http://download.maxmind.com/download/geoip/database/asnum/GeoIPASNum.dat.gz?/GeoIPASNum-2016.06.06.dat.gz) builder at pld:~/rpm/packages/GeoIP-db-IPASNum$ md5sum GeoIPASNum-2016.06.06.dat.gz 0a384c96479df8616116da9f12bcd471 GeoIPASNum-2016.06.06.dat.gz From gotar at polanet.pl Wed Jun 8 11:58:50 2016 From: gotar at polanet.pl (Tomasz Pala) Date: Wed, 8 Jun 2016 11:58:50 +0200 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <883791A9-6028-4CBA-A772-9DAD0BD34568@me.com> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <20160607180731.GB1140@polanet.pl> <6A1D059D-727A-45DF-9D44-5024562A5B05@me.com> <20160608025729.GA1989@polanet.pl> <883791A9-6028-4CBA-A772-9DAD0BD34568@me.com> Message-ID: <20160608095849.GA10042@polanet.pl> On Wed, Jun 08, 2016 at 00:10:36 -0400, Jeffrey Johnson wrote: >> http://lists.rpm.org/pipermail/rpm-maint/2008-February/001911.html > > OK, I???ll bite: you quote James Antill from 8 years ago ??? what are you trying to say? Please ??? > >> FS-level snapshots are shortest way to 'reboot to upgrade' insanity. > > So you seem to not like ???FS snapshots??? ??? Good, I think FS snapshots have little to > do with ???rollback too, we may possibly agree. FS snapshots have a usage case, > but not with ???rollback for package management. I'm just trying to figure out what mechanisms are you suggesting instead repackages - I'm using snapshots, but for other purposes, glad we agree! > All I meant to suggest is that the PLD devel list is _NOT_ the pace to discuss RPM package management > issues (including repackaging, and ???rollback) seriously. OK, listen - I am really only interested in working alternatives if you know any. Not digging into internals, glad we agree! >>> This thread is/was diagnosing a problem and devising a solution, not otherwise. >> >> Different approach to entire repackage (that YOU suggested) is also a solution. > > What are you trying to say here? Do you like/want repackaging or not? I did successfully implement > repackaging (what is currently used by PLD) while @redhat in like 2003 or so. Surely I do! In fact, if it were gone like in RH, I would be probably not using PLD anymore, because it would be unusable for me. > I???m happy you like what I implemented, but damfino what you wish changed. "There are also better solutions than /var/spool/repackage that can be attempted these days" I wish to only know these better solutions you've mentioned. Nothing more. Did you mean something in RPM internals? Or some other mechanism? Tool? Or maybe you meant %config files in repackages are not so important, because this particular issue should be solved via git? > Um, a yum-history citation, and from 2010??? which depends on what is called a ???yumdb??? ??? > is mostly useless, perhaps more useless than FS snapshots that you seem to dislike. So, once again, we agree! > You???ll have to remind me of what I wrote, I have written lots about RPM over the years ??? Oh, it was just one year ago - almost exactly (yet referring to May 2003): https://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2015-June/024388.html But this is about %config - now just seeking if anything new has appeared in those years in regard for entire upgrade transaction, that would make my current workflow obsolete. > Please don???t take my comments personally: I???ll be happy to discuss better RPM > implementations as you wish in an appropriate forum related to RPM, not PLD. I like the current implementation (repackages) and had an impression, that you are proposing _some_ alternative. If, by saing "can be attempted", you had in mind "new mechanism can be _developed_", than yes, it's OT for pld-devel. It just wasn't clear for me, if you suggest attempting to USE _some_ better solution, or attempting to DEVELOP one. We seem to have reached a consensus on this matter. -- Tomasz Pala From n3npq at me.com Wed Jun 8 14:03:46 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Wed, 08 Jun 2016 08:03:46 -0400 Subject: rpm5 (Re: rpm -Uhv --oldpackage loses configs) In-Reply-To: <5757B56C.1030906@delfi.ee> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <57570B32.3040202@delfi.ee> <17C8310B-A13E-4F29-8CE7-90F1911B4E4C@me.com> <57571200.2090106@pld-linux.org> <57571740.4040809@pld-linux.org> <88C950A1-CB8D-4806-ACAD-117C449C94C8@me.com> <5757B56C.1030906@delfi.ee> Message-ID: <32A6B376-2C80-495B-B3ED-08DF4782FAAB@me.com> > On Jun 8, 2016, at 2:04 AM, Elan Ruusam?e wrote: > > On 08.06.2016 01:04, Jeffrey Johnson wrote: >> (aside) >> I spent a week converting the entire @rpm5.org cvs repository to git >> last year at git.rpm.org. There has been exactly zero interest in accessing, >> too little interest to even contemplate switching the repository into >> "production" every day use imho. > and how exactly one should know it should be accessed? > Well, both you and arekm are members of the RPM5 project ,,, which is where a CVS -> GIT conversion was both requested and discussed more than a year ago, I asked for RPM ROADMAP suggestions, and the only suggestion I have received (last year, and repeatedly since 2008) was a deafening chant of GIT! GIT! GIT! GIT! GIT! So I did the conversion and described the result. Not one person (there are at least 4 members of the RPM5 project who have repeatedly asked for a git repository) expressed any interest in the result. *shrug* Apathy ain?t my problem mon, nor do I believe that I should force anyone to use what they asked for. That?s life, mostly a waste of time and effort. > there's no "news" on frontpage, http://rpm5.org/ > says that Production version of RPM is 5.3.6 > clicking "sources" link http://rpm5.org/sources.php gives just cvs info > roadmap http://rpm5.org/roadmap.php speaks about 2007 > last news item is from 2008 http://rpm5.org/news.php > or is it 2009? why it's under 2008? > there's no "blog" either announcing cool and fun stuff that some active projects do > Yep. I also do not announce RPM5 releases, nor advertise RPM5 features, nor advocate RPM5 direction. All these roles are handled by other volunteers @rpm5.org. > the only way to even know about cvs->git, is to subscribe to mailinglist, > again so 1990s. i personally won't do that, it's too much noise to be subscribed to mailing lists. The irony here is that subscribing to project mailing lists are part of _YOUR_ responsibilities as a member of the RPM5 project. So go ask yourself why the content at http://rpm5.org has not changed for many years. > oh, and git.rpm5.org gives centos standard page, so can't even clone the repo to see it's conversion quality. > > ps: you could also write "blog" (mailinglist post in your case) of your cvs2git progress, would be fun to read how you did it, problems encountered, how solved, as i understand rpm5 cvs repo was quite unique, i haven't seen 2.x cvs revisions anywhere else. > Why should I write a blog about a conversion chore? ESR?s instructions (and RSE?s 3 weeks of repository repair work back when RPM5 was launched) were more than adequate, the conversion was rather straight forward. Similarly, why should *I* (as the only active project developer0 use git when cvs is more than adequate for my own development purposes? GIT is great for large distributed active development projects, but all of ?large?, ?distributed? and ?active? do not apply to the RPM5 project, so GIT is rather overkill. I?d also rather not hear the knee-jerk reply Well you have no active developers because you aren?t using GIT! GIT! GIT! See above: I _DID_ the CVS->GIT conversion and no member of the RPM5 project has bothered to even ask for access. > and also i think i've made at least 1 commit to rpm5 cvs repo. i was never contacted to be asked what i wish my author email to be, that is not nice. > Yup, I did not bother converting e-mail addresses. Exactly similar to the @rpm.org git repository, where I am not credited with any commits whatsoever, nor was I asked what my e-mail address currently is. *shrug* 73 de Jeff > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From glen at pld-linux.org Wed Jun 8 14:25:42 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Wed, 8 Jun 2016 15:25:42 +0300 Subject: rpm5 (Re: rpm -Uhv --oldpackage loses configs) In-Reply-To: <32A6B376-2C80-495B-B3ED-08DF4782FAAB@me.com> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <57570B32.3040202@delfi.ee> <17C8310B-A13E-4F29-8CE7-90F1911B4E4C@me.com> <57571200.2090106@pld-linux.org> <57571740.4040809@pld-linux.org> <88C950A1-CB8D-4806-ACAD-117C449C94C8@me.com> <5757B56C.1030906@delfi.ee> <32A6B376-2C80-495B-B3ED-08DF4782FAAB@me.com> Message-ID: <57580EC6.7000701@pld-linux.org> On 08.06.2016 15:03, Jeffrey Johnson wrote: > Similarly, why should*I* (as the only active project developer0 use git when cvs is more than > adequate for my own development purposes? GIT is great for large distributed active development > projects, but all of ?large?, ?distributed? and ?active? do not apply to the RPM5 project, so GIT is > rather overkill. > > I?d also rather not hear the knee-jerk reply > Well you have no active developers because you aren?t using GIT! GIT! GIT! > See above: I_DID_ the CVS->GIT conversion and no member of the RPM5 project > has bothered to even ask for access. well. i will say exactly that! because you use cvs and and you code contributions are simple as submitting PR from github, there are no interested parties submitting anything. and because website is outdated nobody even finds the project. and: submitting PR from github, he/she does not need to be member of rpm5 *team*! do not confuse team-member vs contributors. -- glen From n3npq at me.com Wed Jun 8 15:50:11 2016 From: n3npq at me.com (Jeffrey Johnson) Date: Wed, 08 Jun 2016 09:50:11 -0400 Subject: rpm -Uhv --oldpackage loses configs In-Reply-To: <20160608095849.GA10042@polanet.pl> References: <5755C856.7010101@delfi.ee> <57570461.9090502@delfi.ee> <97517C5D-2ADA-46F0-9FCF-411FECEF3E2B@me.com> <20160607180731.GB1140@polanet.pl> <6A1D059D-727A-45DF-9D44-5024562A5B05@me.com> <20160608025729.GA1989@polanet.pl> <883791A9-6028-4CBA-A772-9DAD0BD34568@me.com> <20160608095849.GA10042@polanet.pl> Message-ID: <99D3270D-0838-4401-9F5C-0F0B718AF454@me.com> > On Jun 8, 2016, at 5:58 AM, Tomasz Pala wrote: > > On Wed, Jun 08, 2016 at 00:10:36 -0400, Jeffrey Johnson wrote: > >>> http://lists.rpm.org/pipermail/rpm-maint/2008-February/001911.html >> >> OK, I???ll bite: you quote James Antill from 8 years ago ??? what are you trying to say? Please ??? >> >>> FS-level snapshots are shortest way to 'reboot to upgrade' insanity. >> >> So you seem to not like ???FS snapshots??? ??? Good, I think FS snapshots have little to >> do with ???rollback too, we may possibly agree. FS snapshots have a usage case, >> but not with ???rollback for package management. > > I'm just trying to figure out what mechanisms are you suggesting instead > repackages - I'm using snapshots, but for other purposes, glad we agree! > I am suggesting that storing possibly gigabytes of repackaged data on every client disk is rather silly for largely identical redundant content. Consider a data center, with dozens of racks and thousands of disks, all being maintained with automated package management. The usage case when the datacenter is hosting dozens of VM?s is even more obvious when you look at repackaging. Repackaging erased content into /var/spool/repackage isn?t close to being the right engineering for a data center usage case, and even for smaller SOHO deployments, the multiple gigabytes of largely redundant identical content are rather pointless. >> All I meant to suggest is that the PLD devel list is _NOT_ the pace to discuss RPM package management >> issues (including repackaging, and ???rollback) seriously. > > OK, listen - I am really only interested in working alternatives if you know any. > Not digging into internals, glad we agree! > Working alternatives to what? Repackaging or rollback? Repackaging SHOULD be handled by returning to the original rpm content and preserving a per-machine delta patch of modified (usually configuration) content. Recreating some machine state from *.rpm blobs and a client delta is not rocket science with tools like mongoldb/git. Rollback (and ACID behavior for package/content management) is usually implemented by serializing the sequence of invertible (i.e. rpm -e is the inverse of rpm -i and vice versa) actions in a log and then replaying committed transactions forwards/backwards. That too has flaws: 1) the log can/will require as much space as the content being managed 2) replaying the log involves rewriting Gb of data and compression eats cpu cycles. What everyone really wants is the ability to cherry pick Hmm that upgrade broke something, lets backup to last known good for some packages. and the serialization implemented by ACID and logs is rather massively useless for ?cherry picking?. (aside) There?s likely a master?s thesis (and perhaps a company or career) available to someone who can devise a partial ACID rollback under constraints like preserving dependency closure. I?ve searched for an answer to how to compute a subset partial ACID rollback (i.e. cherry picking just those packages that need to be replaced to get rid of a few bad packages) without success. >>>> This thread is/was diagnosing a problem and devising a solution, not otherwise. >>> >>> Different approach to entire repackage (that YOU suggested) is also a solution. >> >> What are you trying to say here? Do you like/want repackaging or not? I did successfully implement >> repackaging (what is currently used by PLD) while @redhat in like 2003 or so. > > Surely I do! In fact, if it were gone like in RH, I would be probably > not using PLD anymore, because it would be unusable for me. > I?m glad you like repackaging as implemented. >> I???m happy you like what I implemented, but damfino what you wish changed. > > "There are also better solutions than /var/spool/repackage that can be > attempted these days" > > I wish to only know these better solutions you've mentioned. Nothing > more. Did you mean something in RPM internals? Or some other mechanism? > Tool? Or maybe you meant %config files in repackages are not so > important, because this particular issue should be solved via git? > RPM carries the mongo-c-driver and libgit2 (and a butt load of creepy-toe to ensure no tampering) in order to attempt a better solution to rollback and repository management. The harder issue is setting up a server side infrastructure from which package metadata and file content can be retrieved. The server-side schema?s are not very complex header?s always have a SHA1 associated that can be used as part of a retrieval key files always have a digest that can be used as part of a retrieval key The digests should not be used directly as a retrieval key, but rather should be wrapped into a UUID with an administrative name space so that, say, PLD and Poky/Yocto could each have their own unique retrieval key even when the actual content is identical. Given a reliable distributed server indexed as above, the need for a local /var/spool/repackage disappears. And as long as the original content (not just the unmodified content digest) is accessible, then recreating a *.rpm package when needed, or even creating a drpm delta package, can be done as needed. Most of the implementations (like the mongo-c-driver and libgit2 and the UUID generation and the ability to generate/sign/verify signatures on blobs) to go after an exploded package Big Data Server store exist in RPM5 for several years now, and I have prototyped various pieces of the client puzzle as time permits. What I haven?t done is integrate any of the development into RPM ?production? code paths. Yet. My development has been underway for quite some time now, called GUPPI Globally Unique Persistent Package Identifiers Think: like a git commit, most modern packages have a SHA1, the rest is just a content store. >> Um, a yum-history citation, and from 2010??? which depends on what is called a ???yumdb??? ??? >> is mostly useless, perhaps more useless than FS snapshots that you seem to dislike. > > So, once again, we agree! > >> You???ll have to remind me of what I wrote, I have written lots about RPM over the years ??? > > Oh, it was just one year ago - almost exactly (yet referring to May 2003): > https://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2015-June/024388.html > But this is about %config - now just seeking if anything new has appeared in > those years in regard for entire upgrade transaction, that would make my current workflow obsolete. > >> Please don???t take my comments personally: I???ll be happy to discuss better RPM >> implementations as you wish in an appropriate forum related to RPM, not PLD. > > I like the current implementation (repackages) and had an impression, > that you are proposing _some_ alternative. If, by saing "can be > attempted", you had in mind "new mechanism can be _developed_", than > yes, it's OT for pld-devel. It just wasn't clear for me, if you suggest > attempting to USE _some_ better solution, or attempting to DEVELOP one. > > We seem to have reached a consensus on this matter. > I hope the above clarifies where I am headed at least somewhat. We now return the thread to discussions of %config actions on downgrades to repackaged packages ? 73 de Jeff > -- > Tomasz Pala > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From qboosh at pld-linux.org Wed Jun 8 16:09:37 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 8 Jun 2016 16:09:37 +0200 Subject: selinuxfs mount point Message-ID: <20160608140936.GA23972@stranger.qboosh.pl> Probably since 2011 (libselinux 2.1.1) preferred selinuxfs mount point is /sys/fs/selinux (with fallback to /selinux and any other location selinuxfs is detected at). OK to adjust rc.sysinit? Does anything more need update (beside dropping /selinux from filesystem.spec)? -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Wed Jun 8 18:29:33 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 8 Jun 2016 18:29:33 +0200 Subject: selinuxfs mount point In-Reply-To: <20160608140936.GA23972@stranger.qboosh.pl> References: <20160608140936.GA23972@stranger.qboosh.pl> Message-ID: <20160608162933.GA15344@mail> On Wed, Jun 08, 2016 at 04:09:37PM +0200, Jakub Bogusz wrote: > Probably since 2011 (libselinux 2.1.1) preferred selinuxfs mount point > is /sys/fs/selinux (with fallback to /selinux and any other location > selinuxfs is detected at). > > OK to adjust rc.sysinit? > Does anything more need update (beside dropping /selinux from filesystem.spec)? Uhm, it seems that the new location is supported since Linux 3.0, so filesystem/rc-scripts compatibility fallback (if test -d /sys/fs/selinux; then mount /sys/fs/selinux else mount /selinux) needs to stay as long as 2.6.x is supported in Th. -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Fri Jun 10 17:04:36 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Fri, 10 Jun 2016 18:04:36 +0300 Subject: [packages/GeoIP-db-IPASNum] updated to 2016.06.06 In-Reply-To: <20160608120106.6b8b4567@zonk.pl> References: <2b32b421191f339f1045ff94b9fbc89b0e65bcd5_refs_heads_master@pld-linux.org> <20160608095304.6b8b4567@zonk.pl> <57580143.7020503@pld-linux.org> <20160608120106.6b8b4567@zonk.pl> Message-ID: <575AD704.30502@pld-linux.org> On 08.06.2016 15:01, Adam Osuchowski wrote: > Elan Ruusam?e wrote: >> yours had invalid timestamp, so i assumed mine is correct > Valid timestamp should be 2016.06.07 because, according to > http://dev.maxmind.com/geoip/legacy/geolite/, databases are updated > on the first Tuesday of each month, and it was June 7th not 6th. no, valid timestamp is 2016.06.06, if look at the file in UTC timestamp: [~/rpm/geo-packages/GeoIP-db-IPASNum(2016.06.06) (master)?] ? TZ=UTC LC_ALL=C ls -l *gz -rw-r----- 1 glen users 2070384 Jun 6 22:35 GeoIPASNum-2016.06.06.dat.gz [~/rpm/geo-packages/GeoIP-db-IPASNum(2016.06.06) (master)?] ? TZ=CET LC_ALL=C ls -l *gz -rw-r----- 1 glen users 2070384 Jun 7 00:35 GeoIPASNum-2016.06.06.dat.gz [~/rpm/geo-packages/GeoIP-db-IPASNum(2016.06.06) (master)?] ? TZ=EET LC_ALL=C ls -l *gz -rw-r----- 1 glen users 2070384 Jun 7 01:35 GeoIPASNum-2016.06.06.dat.gz [~/rpm/geo-packages/GeoIP-db-IPASNum(2016.06.06) (master)?] ? so, you got correct md5, but wrong timestamp i got wrong md5 but correct timestamp so anyway, updated md5 and distfiles was able to fetch it -- glen From qboosh at pld-linux.org Sat Jun 11 17:40:40 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sat, 11 Jun 2016 17:40:40 +0200 Subject: ERRORS: openchange.spec In-Reply-To: References: Message-ID: <20160611154039.GA3620@mail> Is something suspicious happening with th-i686? This ICE seems non-deterministic (test-build succeeded then)... Also libpng tests failed non-deterministically on th-i686. On Fri, Jun 10, 2016 at 07:52:45PM +0000, PLD th-i686 builder wrote: > Request by: qboosh at pld-linux.org > > openchange.spec (HEAD): FAILED [...] > Compiling gen_ndr/ndr_exchange.c with -fPIC > i686-pld-linux-gcc -I/usr/include/python2.7 -I/usr/include/python2.7 -fno-strict-aliasing -O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i686 -fasynchronous-unwind-tables -mtune=pentium4 -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -DNDEBUG -O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i686 -fasynchronous-unwind-tables -mtune=pentium4 -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -I. -O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i68 > 6 -fasynchronous-unwind-tables -mtune=pentium4 -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -DHAVE_LITTLE_ENDIAN -Wall -fstrict-aliasing -Wp,-D_FORTIFY_SOURCE=2 -Wmissing-prototypes -Wstrict-prototypes -Wpointer-sign -DENABLE_ASSERTS -DDEFAULT_LDIF=\"/usr/share/openchange/setup/profiles\" -DMAPISTORE_LDIF=\"/usr/share/openchange/setup/mapistore\" -DOPENCHANGEDB_DATA_DIR=\"/usr/share/openchange/setup/openchangedb\" -DMAPISTORE_BACKEND_INSTALLDIR=\"/usr/lib/mapistore_backends\" -DLZXPRESS_DATADIR=\"/usr/share/openchange/mapitest/lzxpress\" -DLZFU_DATADIR=\"/usr/share/openchange/mapitest/lzfu\" -DHAVE_ICAL_0_46=1 -DHAVE_IMMEDIATE_STRUCTURES=1 -D_GNU_SOURCE=1 -DHAVE_IMMEDIATE_STRUCTURES=1 -I/usr/include/samba-4.0 -fPIC -c gen_ndr/ndr_exchange.c -o gen_ndr/ndr_exchange.po > gen_ndr/ndr_exchange.c: In function 'ndr_push_RecipientRow': > gen_ndr/ndr_exchange.c:47851:1: internal compiler error: in create_edge, at cgraph.c:869 > }; > ^ > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > Makefile:124: recipe for target 'gen_ndr/ndr_exchange.po' failed > make: *** [gen_ndr/ndr_exchange.po] Error 1 > error: Bad exit status from /tmp/B.MA_tQF/BUILD/tmp/rpm-tmp.76302 (%build) -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Sat Jun 11 23:00:40 2016 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Sat, 11 Jun 2016 23:00:40 +0200 Subject: ERRORS: openchange.spec In-Reply-To: <20160611154039.GA3620@mail> References: <20160611154039.GA3620@mail> Message-ID: <201606112300.40592.arekm@maven.pl> On Saturday 11 of June 2016, Jakub Bogusz wrote: > Is something suspicious happening with th-i686? > This ICE seems non-deterministic (test-build succeeded then)... Seems so as it stopped booting now and I can't do much remotely (ipmi console is black). buildlogs are on the same machine, so down, too. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Tue Jun 14 09:13:31 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 14 Jun 2016 10:13:31 +0300 Subject: ERRORS: openchange.spec In-Reply-To: <201606112300.40592.arekm@maven.pl> References: <20160611154039.GA3620@mail> <201606112300.40592.arekm@maven.pl> Message-ID: <575FAE9B.1090409@pld-linux.org> On 12.06.2016 00:00, Arkadiusz Mi?kiewicz wrote: > Seems so as it stopped booting now and I can't do much remotely (ipmi console > is black). can you run th-i686 elsewhere meanwhile? i.e th-x86_64, should be just simple config change. for example all ac-*x86* builders run on same machine. -- glen From arekm at maven.pl Tue Jun 14 09:17:10 2016 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Tue, 14 Jun 2016 09:17:10 +0200 Subject: ERRORS: openchange.spec In-Reply-To: <575FAE9B.1090409@pld-linux.org> References: <201606112300.40592.arekm@maven.pl> <575FAE9B.1090409@pld-linux.org> Message-ID: <201606140917.10359.arekm@maven.pl> On Tuesday 14 of June 2016, Elan Ruusam?e wrote: > On 12.06.2016 00:00, Arkadiusz Mi?kiewicz wrote: > > Seems so as it stopped booting now and I can't do much remotely (ipmi > > console is black). > > can you run th-i686 elsewhere meanwhile? i.e th-x86_64, should be just > simple config change. for example all ac-*x86* builders run on same > machine. I'm waiting for courier to deliver broken i686 machine to me today and will see what is happening with it first. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Tue Jun 14 16:28:51 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 14 Jun 2016 17:28:51 +0300 Subject: ERRORS: openchange.spec In-Reply-To: <201606140917.10359.arekm@maven.pl> References: <201606112300.40592.arekm@maven.pl> <575FAE9B.1090409@pld-linux.org> <201606140917.10359.arekm@maven.pl> Message-ID: <576014A3.4000506@pld-linux.org> On 14.06.2016 10:17, Arkadiusz Mi?kiewicz wrote: > On Tuesday 14 of June 2016, Elan Ruusam?e wrote: >> >On 12.06.2016 00:00, Arkadiusz Mi?kiewicz wrote: >>> > >Seems so as it stopped booting now and I can't do much remotely (ipmi >>> > >console is black). >> > >> >can you run th-i686 elsewhere meanwhile? i.e th-x86_64, should be just >> >simple config change. for example all ac-*x86* builders run on same >> >machine. > I'm waiting for courier to deliver broken i686 machine to me today and will > see what is happening with it first. but this will kind of "stall" pld development, because i won't send stuff to builders now without knowing all builders can finish (i.e test build before release build), and later i will just forget.... dunno what about others... -- glen From arekm at maven.pl Wed Jun 15 13:40:25 2016 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Wed, 15 Jun 2016 13:40:25 +0200 Subject: ERRORS: openchange.spec In-Reply-To: <576014A3.4000506@pld-linux.org> References: <201606140917.10359.arekm@maven.pl> <576014A3.4000506@pld-linux.org> Message-ID: <201606151340.25818.arekm@maven.pl> On Tuesday 14 of June 2016, Elan Ruusam?e wrote: > On 14.06.2016 10:17, Arkadiusz Mi?kiewicz wrote: > > On Tuesday 14 of June 2016, Elan Ruusam?e wrote: > >> >On 12.06.2016 00:00, Arkadiusz Mi?kiewicz wrote: > >>> > >Seems so as it stopped booting now and I can't do much remotely > >>> > >(ipmi console is black). > >> > > >> >can you run th-i686 elsewhere meanwhile? i.e th-x86_64, should be just > >> >simple config change. for example all ac-*x86* builders run on same > >> >machine. > > > > I'm waiting for courier to deliver broken i686 machine to me today and > > will see what is happening with it first. > > but this will kind of "stall" pld development, because i won't send > stuff to builders now without knowing all builders can finish (i.e test > build before release build), and later i will just forget.... > dunno what about others... th-i686 and buildlogs is back to life -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From jajcus at jajcus.net Wed Jun 15 14:10:03 2016 From: jajcus at jajcus.net (Jacek Konieczny) Date: Wed, 15 Jun 2016 14:10:03 +0200 Subject: ERRORS: openchange.spec In-Reply-To: <201606151340.25818.arekm@maven.pl> References: <201606140917.10359.arekm@maven.pl> <576014A3.4000506@pld-linux.org> <201606151340.25818.arekm@maven.pl> Message-ID: <3d3145ee-74de-9912-8af3-86b277567b3e@jajcus.net> On 2016-06-15 13:40, Arkadiusz Mi?kiewicz wrote: > th-i686 and buildlogs is back to life buildlogs do not seem right: http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=1&name=wget&id=77718e81-0246-4533-aa72-d97b07abbd8e&action=tail Jacek From arekm at maven.pl Wed Jun 15 14:20:44 2016 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Wed, 15 Jun 2016 14:20:44 +0200 Subject: ERRORS: openchange.spec In-Reply-To: <3d3145ee-74de-9912-8af3-86b277567b3e@jajcus.net> References: <201606151340.25818.arekm@maven.pl> <3d3145ee-74de-9912-8af3-86b277567b3e@jajcus.net> Message-ID: <201606151420.44764.arekm@maven.pl> On Wednesday 15 of June 2016, Jacek Konieczny wrote: > On 2016-06-15 13:40, Arkadiusz Mi?kiewicz wrote: > > th-i686 and buildlogs is back to life > > buildlogs do not seem right: > > http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=1&name=wge > t&id=77718e81-0246-4533-aa72-d97b07abbd8e&action=tail unfortunately... recovering from lost+found ;/ > Jacek -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Thu Jun 16 16:05:09 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 16 Jun 2016 17:05:09 +0300 Subject: libcurl, nghttp2, .etc Message-ID: <5762B215.9030001@pld-linux.org> to: whoever updated packages on cvs@ and probably .spec Conflicts, or Requires should be updated on related packages to avoid such errors [~/rpm/packages/composer(1.1.2) (master)??] ? git push Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 329 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: Traceback (most recent call last): remote: File "hooks/post-receive.d/post-receive-fedmsg", line 10, in remote: import pygit2 remote: File "/tmp/B.yY5JWQ/BUILD/pygit2-0.24.0/build-2/lib.linux-x86_64-2.7/pygit2/__init__.py", line 32, in remote: ImportError: /usr/lib64/libcurl.so.4: undefined symbol: nghttp2_session_callbacks_set_error_callback remote: 2016-06-16 17:02:57 Warning: No server certificate defined; TLS connections will fail. remote: Suggested action: either install a certificate or change tls_advertise_hosts option To ssh://git at git.pld-linux.org/packages/composer 175f7c7..70be704 master -> master -- glen From glen at pld-linux.org Thu Jun 16 16:51:09 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 16 Jun 2016 17:51:09 +0300 Subject: ERRORS: openchange.spec In-Reply-To: <201606151340.25818.arekm@maven.pl> References: <201606140917.10359.arekm@maven.pl> <576014A3.4000506@pld-linux.org> <201606151340.25818.arekm@maven.pl> Message-ID: <5762BCDD.9020601@pld-linux.org> On 15.06.2016 14:40, Arkadiusz Mi?kiewicz wrote: > th-i686 and buildlogs is back to life looks like dns/networking issues: http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=mate-panel&id=a3730967-3ee3-4a67-8eef-4c141b384b1b&action=tail -- glen From arekm at maven.pl Thu Jun 16 18:09:51 2016 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Thu, 16 Jun 2016 18:09:51 +0200 Subject: ERRORS: openchange.spec In-Reply-To: <5762BCDD.9020601@pld-linux.org> References: <201606151340.25818.arekm@maven.pl> <5762BCDD.9020601@pld-linux.org> Message-ID: <201606161809.51636.arekm@maven.pl> On Thursday 16 of June 2016, Elan Ruusam?e wrote: > On 15.06.2016 14:40, Arkadiusz Mi?kiewicz wrote: > > th-i686 and buildlogs is back to life > > looks like dns/networking issues: > > http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=mate- > panel&id=a3730967-3ee3-4a67-8eef-4c141b384b1b&action=tail Not sure what's there since buildlogs.pld-linux.org resolves to old IP for me :-/ Seems ns2.pld-linux is not working correctly and did not update from svn adamg? -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Thu Jun 16 18:15:47 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 16 Jun 2016 19:15:47 +0300 Subject: ERRORS: openchange.spec In-Reply-To: <201606161809.51636.arekm@maven.pl> References: <201606151340.25818.arekm@maven.pl> <5762BCDD.9020601@pld-linux.org> <201606161809.51636.arekm@maven.pl> Message-ID: <5762D0B3.3040709@pld-linux.org> On 16.06.2016 19:09, Arkadiusz Mi?kiewicz wrote: > On Thursday 16 of June 2016, Elan Ruusam?e wrote: >> On 15.06.2016 14:40, Arkadiusz Mi?kiewicz wrote: >>> th-i686 and buildlogs is back to life >> looks like dns/networking issues: >> >> http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=mate- >> panel&id=a3730967-3ee3-4a67-8eef-4c141b384b1b&action=tail > Not sure what's there since buildlogs.pld-linux.org resolves to old IP for me > :-/ Seems ns2.pld-linux is not working correctly and did not update from svn $ curl -s 'http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&ns=0&cnt=50&off=0&name=composer&id=edaba94a-a3c9-4a35-8702-ed4c92393507&action=text'|sprunge http://sprunge.us/REGL Retrieving th::packages.ndir.md... error: vfff: unable to connect to ftp1.pld-linux.org:21: Temporary failure in name resolution Retrying...(#2) error: vfff: unable to connect to ftp1.pld-linux.org:21: Temporary failure in name resolution Retrying...(#3) -- glen From qboosh at pld-linux.org Thu Jun 16 18:22:34 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 16 Jun 2016 18:22:34 +0200 Subject: ERRORS: openchange.spec In-Reply-To: <5762BCDD.9020601@pld-linux.org> References: <201606140917.10359.arekm@maven.pl> <576014A3.4000506@pld-linux.org> <201606151340.25818.arekm@maven.pl> <5762BCDD.9020601@pld-linux.org> Message-ID: <20160616162234.GA32377@mail> On Thu, Jun 16, 2016 at 05:51:09PM +0300, Elan Ruusam?e wrote: > On 15.06.2016 14:40, Arkadiusz Mi?kiewicz wrote: > >th-i686 and buildlogs is back to life > looks like dns/networking issues: > > http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=mate-panel&id=a3730967-3ee3-4a67-8eef-4c141b384b1b&action=tail Also build mails from th-i686 seem not to be delivered. -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Thu Jun 16 18:29:16 2016 From: arekm at maven.pl (Arkadiusz =?iso-8859-2?q?Mi=B6kiewicz?=) Date: Thu, 16 Jun 2016 18:29:16 +0200 Subject: ERRORS: openchange.spec In-Reply-To: <20160616162234.GA32377@mail> References: <5762BCDD.9020601@pld-linux.org> <20160616162234.GA32377@mail> Message-ID: <201606161829.16288.arekm@maven.pl> On Thursday 16 of June 2016, Jakub Bogusz wrote: > On Thu, Jun 16, 2016 at 05:51:09PM +0300, Elan Ruusam?e wrote: > > On 15.06.2016 14:40, Arkadiusz Mi?kiewicz wrote: > > >th-i686 and buildlogs is back to life > > > > looks like dns/networking issues: > > > > http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=mat > > e-panel&id=a3730967-3ee3-4a67-8eef-4c141b384b1b&action=tail > > Also build mails from th-i686 seem not to be delivered. uh exim: error while loading shared libraries: libsrs_alt.so.1: cannot open shared object file: No such file or directory so old emails are lost. Fixed. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From arekm at maven.pl Thu Jun 16 18:29:46 2016 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Thu, 16 Jun 2016 18:29:46 +0200 Subject: ERRORS: openchange.spec In-Reply-To: <5762D0B3.3040709@pld-linux.org> References: <201606161809.51636.arekm@maven.pl> <5762D0B3.3040709@pld-linux.org> Message-ID: <201606161829.46975.arekm@maven.pl> On Thursday 16 of June 2016, Elan Ruusam?e wrote: > On 16.06.2016 19:09, Arkadiusz Mi?kiewicz wrote: > > On Thursday 16 of June 2016, Elan Ruusam?e wrote: > >> On 15.06.2016 14:40, Arkadiusz Mi?kiewicz wrote: > >>> th-i686 and buildlogs is back to life > >> > >> looks like dns/networking issues: > >> > >> http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=ma > >> te- panel&id=a3730967-3ee3-4a67-8eef-4c141b384b1b&action=tail > > > > Not sure what's there since buildlogs.pld-linux.org resolves to old IP > > for me > > > > :-/ Seems ns2.pld-linux is not working correctly and did not update from > > :svn > > $ curl -s > 'http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&ns=0&cnt= > 50&off=0&name=composer&id=edaba94a-a3c9-4a35-8702-ed4c92393507&action=text' > |sprunge > > > http://sprunge.us/REGL > > > > Retrieving th::packages.ndir.md... > error: vfff: unable to connect to ftp1.pld-linux.org:21: Temporary failure > in name resolution Retrying...(#2) > error: vfff: unable to connect to ftp1.pld-linux.org:21: Temporary failure > in name resolution Retrying...(#3) Fixed, too. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Thu Jun 16 19:39:22 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 16 Jun 2016 20:39:22 +0300 Subject: ERRORS: openchange.spec In-Reply-To: <201606161809.51636.arekm@maven.pl> References: <201606151340.25818.arekm@maven.pl> <5762BCDD.9020601@pld-linux.org> <201606161809.51636.arekm@maven.pl> Message-ID: <5762E44A.4040007@pld-linux.org> On 16.06.2016 19:09, Arkadiusz Mi?kiewicz wrote: > Not sure what's there since buildlogs.pld-linux.org resolves to old IP for me > :-/ Seems ns2.pld-linux is not working correctly and did not update from svn this stopped working for me too, i'm getting "old" ip now as well. [~] ? dig buildlogs.pld-linux.org ; <<>> DiG 9.10.4 <<>> buildlogs.pld-linux.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25591 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;buildlogs.pld-linux.org. IN A ;; ANSWER SECTION: buildlogs.pld-linux.org. 3485 IN A 193.239.45.180 ;; Query time: 63 msec ;; SERVER: 10.1.0.120#53(10.1.0.120) ;; WHEN: N juuni 16 20:38:25 EEST 2016 ;; MSG SIZE rcvd: 68 > > adamg? -- glen From glen at pld-linux.org Fri Jun 17 17:25:29 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Fri, 17 Jun 2016 18:25:29 +0300 Subject: libcurl, nghttp2, .etc In-Reply-To: <5762B215.9030001@pld-linux.org> References: <5762B215.9030001@pld-linux.org> Message-ID: <57641669.403@pld-linux.org> whoever broke it fix it! ? git push Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 329 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: Traceback (most recent call last): remote: File "hooks/post-receive.d/post-receive-fedmsg", line 10, in remote: import pygit2 remote: File "/tmp/B.yY5JWQ/BUILD/pygit2-0.24.0/build-2/lib.linux-x86_64-2.7/pygit2/__init__.py", line 32, in remote: ImportError: /usr/lib64/libcurl.so.4: undefined symbol: nghttp2_session_callbacks_set_error_callback remote: 2016-06-17 17:33:53 Warning: No server certificate defined; TLS connections will fail. remote: Suggested action: either install a certificate or change tls_advertise_hosts option To ssh://git at git.pld-linux.org/packages/git-core 29d5b07..9e9faf9 HEAD -> master packages seem to be fixed in git repo, so whoever upgraded cvs.pld-linux.org packages, act! On 16.06.2016 17:05, Elan Ruusam?e wrote: > to: whoever updated packages on cvs@ > > and probably .spec Conflicts, or Requires should be updated on related > packages to avoid such errors > > [~/rpm/packages/composer(1.1.2) (master)??] ? git push > Counting objects: 3, done. > Delta compression using up to 4 threads. > Compressing objects: 100% (3/3), done. > Writing objects: 100% (3/3), 329 bytes | 0 bytes/s, done. > Total 3 (delta 2), reused 0 (delta 0) > remote: Traceback (most recent call last): > remote: File "hooks/post-receive.d/post-receive-fedmsg", line 10, in > > remote: import pygit2 > remote: File > "/tmp/B.yY5JWQ/BUILD/pygit2-0.24.0/build-2/lib.linux-x86_64-2.7/pygit2/__init__.py", > line 32, in > remote: ImportError: /usr/lib64/libcurl.so.4: undefined symbol: > nghttp2_session_callbacks_set_error_callback > remote: 2016-06-16 17:02:57 Warning: No server certificate defined; > TLS connections will fail. > remote: Suggested action: either install a certificate or change > tls_advertise_hosts option > To ssh://git at git.pld-linux.org/packages/composer > 175f7c7..70be704 master -> master > -- glen From mateusz-lists at ant.gliwice.pl Sat Jun 18 12:31:35 2016 From: mateusz-lists at ant.gliwice.pl (Mateusz Korniak) Date: Sat, 18 Jun 2016 10:31:35 +0000 Subject: .so: undefined reference to `ebx' (lizardfs @ i686) Message-ID: <1662972.F7LBrAUosG@matkor-lenovo> Any hint why build of lizarfs fails on i686 with: cd /home/users/matkor/rpm/BUILD/lizardfs-v.3.9.4/build/src/admin && /usr/bin/cmake -E cmake_link_script CMakeFiles/lizardfs-admin.dir/link.txt -- verbose=1 /usr/bin/i686-pld-linux-g++ -pipe -std=c++0x -pthread -Wall -Wextra -fwrapv -pedantic -O3 -DNDEBUG -O3 -DNDEBUG -g CMakeFiles/lizardfs- admin.dir/main.cc.o -o lizardfs-admin -rdynamic liblizardfs-admin-lib.so ../common/libmfscommon.so ../../external/libcrcutil.so -lz -lrt -Wl,- rpath,/home/users/matkor/rpm/BUILD/lizardfs- v.3.9.4/build/src/admin:/home/users/matkor/rpm/BUILD/lizardfs- v.3.9.4/build/src/common:/home/users/matkor/rpm/BUILD/lizardfs- v.3.9.4/build/external: ../../external/libcrcutil.so: undefined reference to `ebx' while built with original set of flags [1] builds OK ? [1] cmake .. -DCMAKE_BUILD_TYPE=Release make matkor at carme-pld-i686 lizardfs-v.3.9.4]$ grep -r ebx * Binary file build/external/CMakeFiles/crcutil.dir/crcutil-1.0/code/crc32c_sse4.cc.o matches Binary file build/external/libcrcutil.so matches external/crcutil-1.0/code/crc32c_sse4.cc: "push ebx\n" external/crcutil-1.0/code/crc32c_sse4.cc: "pop ebx\n" external/crcutil-1.0/code/crc32c_sse4.cc: : "%ebx" external/crcutil-1.0/code/multiword_64_64_cl_i386_mmx.cc:#define TMP1 ebx -- Mateusz Korniak "(...) mam brata - powa?ny, domator, liczykrupa, hipokryta, pobo?ni?, kr?tko m?wi?c - podpora spo?ecze?stwa." Nikos Kazantzakis - "Grek Zorba" From adamg at pld-linux.org Sun Jun 19 10:31:38 2016 From: adamg at pld-linux.org (Adam Golebiowski) Date: Sun, 19 Jun 2016 10:31:38 +0200 Subject: ERRORS: openchange.spec In-Reply-To: <201606161809.51636.arekm@maven.pl> References: <201606151340.25818.arekm@maven.pl> <5762BCDD.9020601@pld-linux.org> <201606161809.51636.arekm@maven.pl> Message-ID: <20160619083138.GA30042@adamg.eu> On Thu, Jun 16, 2016 at 06:09:51PM +0200, Arkadiusz Mi?kiewicz wrote: > Not sure what's there since buildlogs.pld-linux.org resolves to old IP for me > :-/ Seems ns2.pld-linux is not working correctly and did not update from svn > > adamg? Just return from a leave - dns is fixed on ns2, ns3 will be handled shortly From baggins at pld-linux.org Sun Jun 19 22:11:06 2016 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 19 Jun 2016 22:11:06 +0200 Subject: [packages/linux-firmware] add firmware subackages from fedora packaging In-Reply-To: <35908f4eb0b56206dd2055d647afe07e96fe377b_refs_heads_master@pld-linux.org> References: <86ca8c6290871c62414b0d0075adda2b11130d2a_refs_heads_master@pld-linux.org> <35908f4eb0b56206dd2055d647afe07e96fe377b_refs_heads_master@pld-linux.org> Message-ID: <20160619201106.GA7445@tachikoma.lan> On Sun, 19 Jun 2016, glen wrote: > commit 35908f4eb0b56206dd2055d647afe07e96fe377b > Author: Elan Ruusam?e > Date: Sun Jun 19 22:17:39 2016 +0300 > > add firmware subackages from fedora packaging > > there could be more added, just was easier to add what already existed What's the point of this change? To complicate life for people? Having them guess which of multitude firmware packages to pick? Fedora doing something is not a recommendation to do the same. > > linux-firmware.spec | 395 +++++++++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 362 insertions(+), 33 deletions(-) > --- > diff --git a/linux-firmware.spec b/linux-firmware.spec > index 3a94d67..c5c9b3c 100644 > --- a/linux-firmware.spec > +++ b/linux-firmware.spec > @@ -1,15 +1,17 @@ > # TODO > # - subpackages for various firmwares? > +%define rel 2 > +%define ver 20160609 > Summary: Firmware files used by the Linux kernel > Summary(pl.UTF-8): Pliki firmware'u u?ywane przez j?dro Linuksa > Name: linux-firmware > -Version: 20160609 > -Release: 2 > +Version: %{ver} > +Release: %{rel} > License: GPL+ and GPL v2+ and MIT and Redistributable, no modification permitted > Group: Base/Kernel > Source0: http://pkgs.fedoraproject.org/repo/pkgs/linux-firmware/%{name}-%{version}.tar.gz/2bf6ad095ebdf388a99919ca2317b4aa/linux-firmware-%{version}.tar.gz > # Source0-md5: 2bf6ad095ebdf388a99919ca2317b4aa > -URL: http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/ > +URL: https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/ > Obsoletes: microcode-data-amd > BuildArch: noarch > BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n) > @@ -22,6 +24,243 @@ operate. > Ten pakiet zawiera pliki firmware'u wymagane do dzia?ania niekt?rych > urz?dze?. > > +%package -n iwl100-firmware > +Summary: Firmware for Intel(R) Wireless WiFi Link 100 Series Adapters > +Version: 39.31.5.1 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > +Obsoletes: iwl100-firmware < 39.31.5.1-4 > + > +%description -n iwl100-firmware > +This package contains the firmware required by the Intel wireless > +drivers for Linux to support the iwl100 hardware. Usage of the > +firmware is subject to the terms and conditions contained inside the > +provided LICENSE file. Please read it carefully. > + > +%package -n iwl105-firmware > +Summary: Firmware for Intel(R) Centrino Wireless-N 105 Series Adapters > +Version: 18.168.6.1 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > + > +%description -n iwl105-firmware > +This package contains the firmware required by the Intel wireless > +drivers for Linux to support the iwl105 hardware. Usage of the > +firmware is subject to the terms and conditions contained inside the > +provided LICENSE file. Please read it carefully. > + > +%package -n iwl135-firmware > +Summary: Firmware for Intel(R) Centrino Wireless-N 135 Series Adapters > +Version: 18.168.6.1 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > + > +%description -n iwl135-firmware > +This package contains the firmware required by the Intel wireless > +drivers for Linux to support the iwl135 hardware. Usage of the > +firmware is subject to the terms and conditions contained inside the > +provided LICENSE file. Please read it carefully. > + > +%package -n iwl1000-firmware > +Summary: Firmware for Intel(R) PRO/Wireless 1000 B/G/N network adaptors > +Version: 39.31.5.1 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > +Obsoletes: iwl1000-firmware < 1:39.31.5.1-3 > + > +%description -n iwl1000-firmware > +This package contains the firmware required by the Intel wireless > +drivers for Linux to support the iwl1000 hardware. Usage of the > +firmware is subject to the terms and conditions contained inside the > +provided LICENSE file. Please read it carefully. > + > +%package -n iwl2000-firmware > +Summary: Firmware for Intel(R) Centrino Wireless-N 2000 Series Adapters > +Version: 18.168.6.1 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > + > +%description -n iwl2000-firmware > +This package contains the firmware required by the Intel wireless > +drivers for Linux to support the iwl2000 hardware. Usage of the > +firmware is subject to the terms and conditions contained inside the > +provided LICENSE file. Please read it carefully. > + > +%package -n iwl2030-firmware > +Summary: Firmware for Intel(R) Centrino Wireless-N 2030 Series Adapters > +Version: 18.168.6.1 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > + > +%description -n iwl2030-firmware > +This package contains the firmware required by the Intel wireless > +drivers for Linux to support the iwl2030 hardware. Usage of the > +firmware is subject to the terms and conditions contained inside the > +provided LICENSE file. Please read it carefully. > + > +%package -n iwl3945-firmware > +Summary: Firmware for Intel(R) PRO/Wireless 3945 A/B/G network adaptors > +Version: 15.32.2.9 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > +Obsoletes: iwl3945-firmware < 15.32.2.9-7 > + > +%description -n iwl3945-firmware > +This package contains the firmware required by the iwl3945 driver for > +Linux. Usage of the firmware is subject to the terms and conditions > +contained inside the provided LICENSE file. Please read it carefully. > + > +%package -n iwl4965-firmware > +Summary: Firmware for Intel(R) PRO/Wireless 4965 A/G/N network adaptors > +Version: 228.61.2.24 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > +Obsoletes: iwl4965-firmware < 228.61.2.24-5 > + > +%description -n iwl4965-firmware > +This package contains the firmware required by the iwl4965 driver for > +Linux. Usage of the firmware is subject to the terms and conditions > +contained inside the provided LICENSE file. Please read it carefully. > + > +%package -n iwl5000-firmware > +Summary: Firmware for Intel(R) PRO/Wireless 5000 A/G/N network adaptors > +Version: 8.83.5.1_1 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > +Obsoletes: iwl5000-firmware < 8.83.5.1_1-3 > + > +%description -n iwl5000-firmware > +This package contains the firmware required by the iwl5000 driver for > +Linux. Usage of the firmware is subject to the terms and conditions > +contained inside the provided LICENSE file. Please read it carefully. > + > +%package -n iwl5150-firmware > +Summary: Firmware for Intel(R) PRO/Wireless 5150 A/G/N network adaptors > +Version: 8.24.2.2 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > +Obsoletes: iwl5150-firmware < 8.24.2.2-4 > + > +%description -n iwl5150-firmware > +This package contains the firmware required by the iwl5150 driver for > +Linux. Usage of the firmware is subject to the terms and conditions > +contained inside the provided LICENSE file. Please read it carefully. > + > +%package -n iwl6000-firmware > +Summary: Firmware for Intel(R) Wireless WiFi Link 6000 AGN Adapter > +Version: 9.221.4.1 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > +Obsoletes: iwl6000-firmware < 9.221.4.1-4 > + > +%description -n iwl6000-firmware > +This package contains the firmware required by the Intel wireless > +drivers for Linux. Usage of the firmware is subject to the terms and > +conditions contained inside the provided LICENSE file. Please read it > +carefully. > + > +%package -n iwl6000g2a-firmware > +Summary: Firmware for Intel(R) Wireless WiFi Link 6005 Series Adapters > +Version: 18.168.6.1 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > +Obsoletes: iwl6000g2a-firmware < 17.168.5.3-3 > + > +%description -n iwl6000g2a-firmware > +This package contains the firmware required by the Intel wireless > +drivers for Linux. Usage of the firmware is subject to the terms and > +conditions contained inside the provided LICENSE file. Please read it > +carefully. > + > +%package -n iwl6000g2b-firmware > +Summary: Firmware for Intel(R) Wireless WiFi Link 6030 Series Adapters > +Version: 18.168.6.1 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > +Obsoletes: iwl6000g2b-firmware < 17.168.5.2-3 > + > +%description -n iwl6000g2b-firmware > +This package contains the firmware required by the Intel wireless > +drivers for Linux. Usage of the firmware is subject to the terms and > +conditions contained inside the provided LICENSE file. Please read it > +carefully. > + > +%package -n iwl6050-firmware > +Summary: Firmware for Intel(R) Wireless WiFi Link 6050 Series Adapters > +Version: 41.28.5.1 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > +Obsoletes: iwl6050-firmware < 41.28.5.1-5 > + > +%description -n iwl6050-firmware > +This package contains the firmware required by the Intel wireless > +drivers for Linux. Usage of the firmware is subject to the terms and > +conditions contained inside the provided LICENSE file. Please read it > +carefully. > + > +%package -n iwl7260-firmware > +Summary: Firmware for Intel(R) Wireless WiFi Link 7260 Series Adapters > +Version: 25.30.13.0 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > + > +%description -n iwl7260-firmware > +This package contains the firmware required by the Intel wireless > +drivers for Linux. Usage of the firmware is subject to the terms and > +conditions contained inside the provided LICENSE file. Please read it > +carefully. > + > +%package -n iwl3160-firmware > +Summary: Firmware for Intel(R) Wireless WiFi Link 3160 Series Adapters > +Version: 25.30.13.0 > +Release: %{ver}.%{rel} > +License: Redistributable, no modification permitted > + > +%description -n iwl3160-firmware > +This package contains the firmware required by the Intel wireless > +drivers for Linux. Usage of the firmware is subject to the terms and > +conditions contained inside the provided LICENSE file. Please read it > +carefully. > + > +%package -n libertas-usb8388-firmware > +Summary: Firmware for Marvell Libertas USB 8388 Network Adapter > +Version: 0.%{ver} > +Release: %{rel} > +License: Redistributable, no modification permitted > +Obsoletes: libertas-usb8388-firmware < 2:5.110.22.p23-8 > + > +%description -n libertas-usb8388-firmware > +Firmware for Marvell Libertas USB 8388 Network Adapter > + > +%package -n libertas-usb8388-olpc-firmware > +Summary: OLPC firmware for Marvell Libertas USB 8388 Network Adapter > +Version: 0.%{ver} > +Release: %{rel} > +License: Redistributable, no modification permitted > + > +%description -n libertas-usb8388-olpc-firmware > +Firmware for Marvell Libertas USB 8388 Network Adapter with OLPC mesh > +network support. > + > +%package -n libertas-sd8686-firmware > +Summary: Firmware for Marvell Libertas SD 8686 Network Adapter > +Version: 0.%{ver} > +Release: %{rel} > +License: Redistributable, no modification permitted > +Obsoletes: libertas-sd8686-firmware < 9.70.20.p0-4 > + > +%description -n libertas-sd8686-firmware > +Firmware for Marvell Libertas SD 8686 Network Adapter > + > +%package -n libertas-sd8787-firmware > +Summary: Firmware for Marvell Libertas SD 8787 Network Adapter > +Version: 0.%{ver} > +Release: %{rel} > +License: Redistributable, no modification permitted > + > +%description -n libertas-sd8787-firmware > +Firmware for Marvell Libertas SD 8787 Network Adapter > + > %prep > %setup -qc > mv linux-firmware-*/* . > @@ -139,46 +378,21 @@ rm -rf $RPM_BUILD_ROOT > /lib/firmware/intelliport2.bin > /lib/firmware/isci > /lib/firmware/isdbt_*.inp > -/lib/firmware/iwlwifi-100-5.ucode > -/lib/firmware/iwlwifi-105-6.ucode > -/lib/firmware/iwlwifi-135-6.ucode > -/lib/firmware/iwlwifi-2000-6.ucode > -/lib/firmware/iwlwifi-2030-6.ucode > -/lib/firmware/iwlwifi-3160-10.ucode > -/lib/firmware/iwlwifi-3160-12.ucode > -/lib/firmware/iwlwifi-3160-13.ucode > -/lib/firmware/iwlwifi-3160-16.ucode > -/lib/firmware/iwlwifi-3160-7.ucode > -/lib/firmware/iwlwifi-3160-8.ucode > -/lib/firmware/iwlwifi-3160-9.ucode > -/lib/firmware/iwlwifi-3168-21.ucode > -/lib/firmware/iwlwifi-6000g2a-6.ucode > -/lib/firmware/iwlwifi-6050-5.ucode > -/lib/firmware/iwlwifi-7265-10.ucode > -/lib/firmware/iwlwifi-7265-12.ucode > -/lib/firmware/iwlwifi-7265-13.ucode > -/lib/firmware/iwlwifi-7265-16.ucode > -/lib/firmware/iwlwifi-7265-8.ucode > -/lib/firmware/iwlwifi-7265-9.ucode > -/lib/firmware/iwlwifi-7265D-10.ucode > -/lib/firmware/iwlwifi-7265D-12.ucode > -/lib/firmware/iwlwifi-7265D-13.ucode > -/lib/firmware/iwlwifi-7265D-16.ucode > -/lib/firmware/iwlwifi-7265D-21.ucode > -/lib/firmware/iwlwifi-8000C-13.ucode > -/lib/firmware/iwlwifi-8000C-16.ucode > -/lib/firmware/iwlwifi-8000C-21.ucode > -/lib/firmware/iwlwifi-8265-21.ucode > /lib/firmware/kaweth > /lib/firmware/keyspan > /lib/firmware/keyspan_pda > /lib/firmware/lbtf_usb.bin > /lib/firmware/lgs8g75.fw > /lib/firmware/libertas > +%exclude /lib/firmware/libertas/usb8388_v9.bin > +%exclude /lib/firmware/libertas/sd8686* > +%exclude /lib/firmware/libertas/usb8388_olpc.bin > /lib/firmware/liquidio > /lib/firmware/matrox > /lib/firmware/moxa > /lib/firmware/mrvl > +%exclude /lib/firmware/mrvl/sd8787* > +/lib/firmware/mrvl/sd8787* > /lib/firmware/mt7601u.bin > /lib/firmware/mt7650.bin > /lib/firmware/mts_*.fw > @@ -248,3 +462,118 @@ rm -rf $RPM_BUILD_ROOT > /lib/firmware/whiteheat*.fw > /lib/firmware/wsm_22.bin > /lib/firmware/yam > + > +%files -n iwl100-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-100-5.ucode > + > +%files -n iwl105-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-105-*.ucode > + > +%files -n iwl135-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-135-*.ucode > + > +%if 0 > +%files -n iwl1000-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-1000-*.ucode > +%endif > + > +%files -n iwl2000-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-2000-*.ucode > + > +%files -n iwl2030-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-2030-*.ucode > + > +%if 0 > +%files -n iwl3945-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-3945-*.ucode > + > +%files -n iwl4965-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-4965-*.ucode > + > +%files -n iwl5000-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-5000-*.ucode > + > +%files -n iwl5150-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-5150-*.ucode > + > +%files -n iwl6000-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-6000-*.ucode > +%endif > + > +%files -n iwl6000g2a-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-6000g2a-*.ucode > + > +%if 0 > +%files -n iwl6000g2b-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-6000g2b-*.ucode > +%endif > + > +%files -n iwl6050-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-6050-*.ucode > + > +%files -n iwl7260-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +#/lib/firmware/iwlwifi-7260-*.ucode > +/lib/firmware/iwlwifi-7265-*.ucode > +/lib/firmware/iwlwifi-7265D-*.ucode > +/lib/firmware/iwlwifi-8000C-*.ucode > +/lib/firmware/iwlwifi-8265-*.ucode > + > +%files -n iwl3160-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.iwlwifi_firmware > +/lib/firmware/iwlwifi-3160-*.ucode > +/lib/firmware/iwlwifi-3168-*.ucode > + > +%files -n libertas-usb8388-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.Marvell > +%dir /lib/firmware/libertas > +/lib/firmware/libertas/usb8388_v9.bin > + > +%files -n libertas-usb8388-olpc-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.Marvell > +%dir /lib/firmware/libertas > +/lib/firmware/libertas/usb8388_olpc.bin > + > +%files -n libertas-sd8686-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.Marvell > +%dir /lib/firmware/libertas > +/lib/firmware/libertas/sd8686* > + > +%files -n libertas-sd8787-firmware > +%defattr(644,root,root,755) > +%doc WHENCE LICENCE.Marvell > +%dir /lib/firmware/mrvl > +/lib/firmware/mrvl/sd8787* > ================================================================ > > ---- gitweb: > > http://git.pld-linux.org/gitweb.cgi/packages/linux-firmware.git/commitdiff/35908f4eb0b56206dd2055d647afe07e96fe377b > > _______________________________________________ > pld-cvs-commit mailing list > pld-cvs-commit at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From glen at pld-linux.org Mon Jun 20 14:58:11 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 20 Jun 2016 15:58:11 +0300 Subject: python packaging Message-ID: <5767E863.50803@pld-linux.org> so, what way we should do the package naming? 1. egg name 2. python module name [*] 3. upstream tarball name 4. pld own convention [*] this is said to be the recommendation in template-specs reality is that we have no consistency, the package naming is from any of the four choices: the results vary from name letter cases (South vs south), separators (_ vs -), name itself (picklefield module vs django_picklefield egg) [~/relup/python-django-contact-form(1.1) (master)?] ? grep -n '^%{py_sitescriptdir}' ~/all-specs/python-django[-_]*.spec /home/users/glen/all-specs/python-django-assets.spec:59:%{py_sitescriptdir}/django_assets /home/users/glen/all-specs/python-django-assets.spec:60:%{py_sitescriptdir}/django_assets-%{version}-py*.egg-info /home/users/glen/all-specs/python-django-celery.spec:54:%{py_sitescriptdir}/djcelery /home/users/glen/all-specs/python-django-celery.spec:56:%{py_sitescriptdir}/django_celery-%{version}-*.egg-info /home/users/glen/all-specs/python-django-evolution.spec:70:%{py_sitescriptdir}/django_evolution /home/users/glen/all-specs/python-django-evolution.spec:72:%{py_sitescriptdir}/django_evolution-%{version}-*.egg-info /home/users/glen/all-specs/python-django-picklefield.spec:56:%{py_sitescriptdir}/picklefield /home/users/glen/all-specs/python-django-picklefield.spec:58:%{py_sitescriptdir}/django_picklefield-%{version}-*.egg-info/ /home/users/glen/all-specs/python-django-pipeline.spec:58:%{py_sitescriptdir}/pipeline/*.py[co] /home/users/glen/all-specs/python-django-pipeline.spec:59:%{py_sitescriptdir}/pipeline/compilers/*.py[co] /home/users/glen/all-specs/python-django-pipeline.spec:60:%{py_sitescriptdir}/pipeline/compressors/*.py[co] /home/users/glen/all-specs/python-django-pipeline.spec:61:%{py_sitescriptdir}/pipeline/conf/*.py[co] /home/users/glen/all-specs/python-django-pipeline.spec:62:%{py_sitescriptdir}/pipeline/jinja2/*.py[co] /home/users/glen/all-specs/python-django-pipeline.spec:63:%{py_sitescriptdir}/pipeline/templates /home/users/glen/all-specs/python-django-pipeline.spec:64:%{py_sitescriptdir}/pipeline/templatetags/*.py[co] /home/users/glen/all-specs/python-django-pipeline.spec:65:%{py_sitescriptdir}/django_pipeline*.egg-info /home/users/glen/all-specs/python-django-profiles.spec:44:%{py_sitescriptdir}/profiles/*.py[co] /home/users/glen/all-specs/python-django-profiles.spec:45:%{py_sitescriptdir}/django_profiles-%{version}-py*.egg-info /home/users/glen/all-specs/python-django-registration.spec:59:%{py_sitescriptdir}/registration/*.py[co] /home/users/glen/all-specs/python-django-registration.spec:60:%{py_sitescriptdir}/registration/backends /home/users/glen/all-specs/python-django-registration.spec:61:%{py_sitescriptdir}/registration/management /home/users/glen/all-specs/python-django-registration.spec:63:%{py_sitescriptdir}/django_registration-%{version}-py*.egg-info /home/users/glen/all-specs/python-django-skypehub.spec:38:%{py_sitescriptdir}/skypehub /home/users/glen/all-specs/python-django-skypehub.spec:40:%{py_sitescriptdir}/django_skypehub-%{version}-*.egg-info /home/users/glen/all-specs/python-django-south.spec:46:%{py_sitescriptdir}/south /home/users/glen/all-specs/python-django-south.spec:48:%{py_sitescriptdir}/South-*.egg-info /home/users/glen/all-specs/python-django-voting.spec:45:%{py_sitescriptdir}/voting/*.py[co] /home/users/glen/all-specs/python-django-voting.spec:46:%{py_sitescriptdir}/voting/migrations /home/users/glen/all-specs/python-django-voting.spec:47:%{py_sitescriptdir}/voting/templatetags /home/users/glen/all-specs/python-django-voting.spec:48:%{py_sitescriptdir}/django_voting-%{version}-py*.egg-info /home/users/glen/all-specs/python-django_extensions.spec:108:%{py_sitescriptdir}/%{module} /home/users/glen/all-specs/python-django_extensions.spec:109:%{py_sitescriptdir}/%{module}-%{version}-py*.egg-info /home/users/glen/all-specs/python-django_profile.spec:53:%{py_sitescriptdir}/userprofile /home/users/glen/all-specs/python-django_reversion.spec:59:%{py_sitescriptdir}/%{module} /home/users/glen/all-specs/python-django_reversion.spec:60:%{py_sitescriptdir}/django_reversion-%{version}-*.egg-info /home/users/glen/all-specs/python-django_tagging.spec:44:%{py_sitescriptdir}/%{module}/*.py[co] /home/users/glen/all-specs/python-django_tagging.spec:45:%{py_sitescriptdir}/%{module}/templatetags /home/users/glen/all-specs/python-django_tagging.spec:46:%{py_sitescriptdir}/django_tagging-%{version}-py*.egg-info [~/relup/python-django-contact-form(1.1) (master)?] ? -- glen From jajcus at jajcus.net Mon Jun 20 16:11:41 2016 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 20 Jun 2016 16:11:41 +0200 Subject: python packaging In-Reply-To: <5767E863.50803@pld-linux.org> References: <5767E863.50803@pld-linux.org> Message-ID: On 2016-06-20 14:58, Elan Ruusam?e wrote: > so, what way we should do the package naming? > > 1. egg name That probably makes most sense today. > 2. python module name [*] That was decided before python eggs started being a thing. And that is how most of our packages are named now. > 3. upstream tarball name > 4. pld own convention Both would give quite random results. > [*] this is said to be the recommendation in template-specs As it was decided long time ago, when it made sense. > 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. > the package naming is from any of the four choices: > > the results vary from name letter cases (South vs south), separators (_ > vs -), name itself (picklefield module vs django_picklefield egg) I hate this too. Especially when I find out a package exists after I package it again under a more standard name. I think the best naming scheme would be python-${egg_name} now. But that is inconsistent with what we used to do. Renaming all the affected packages might be quite problematic. Anything that doesn't match 1. or 2. should be renamed, but doing it after it went to th causes compatibility problems. Jacek From glen at pld-linux.org Mon Jun 20 17:20:36 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 20 Jun 2016 18:20:36 +0300 Subject: python packaging In-Reply-To: References: <5767E863.50803@pld-linux.org> Message-ID: <576809C4.9020904@pld-linux.org> On 20.06.2016 17:11, Jacek Konieczny wrote: > > I think the best naming scheme would be python-${egg_name} now. But > that is inconsistent with what we used to do. Renaming all the > affected packages might be quite problematic what about name cases, should we lowercase them? (i'd like that, ensures some what consistency) or pyp index names already enforce lowercase? but pyp index name != egg_name likely too? github mirror can't distinguish python-South with python-south (it's all same to it) also i've had case where i used case insensitive filesystem for storing pld mirror -- glen From n3npq at mac.com Mon Jun 20 20:32:09 2016 From: n3npq at mac.com (Jeff Johnson) Date: Mon, 20 Jun 2016 14:32:09 -0400 Subject: python packaging In-Reply-To: References: <5767E863.50803@pld-linux.org> Message-ID: <2FFA5D46-962C-4F5B-A459-CB0B8A6DFD84@mac.com> 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 is up to distros ... BUT ... If you wish naming consistency, then you will likely need detection and enforcement. rpmbuild implementations is one mechanism. rpmbuild already runs *RE's against package name (and more) to prevent (essentially) cross-scripting attacks on contexts where NVR are used in scripting. The *RE's are doing nothing more than limiting the character set being used currently. It would not be hard to apply additional *RE's against, say, python package naming. There is also RPM+SED (i.e. a PCRE sed-like embedding) intended as a better way to do %{?dist} branding in build releases. Basically the equivalent of running rpm -qp --qf '%{release}' *.rpm | sed -e 's/$/%{?dist}/' while building, without adding dependencies on external sed(1). There are many other usage cases for an internal/embedded find-and-replace in RPM. hth 73 de Jeff From qboosh at pld-linux.org Mon Jun 20 21:05:04 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 20 Jun 2016 21:05:04 +0200 Subject: [packages/boost] future todo: use .7z download In-Reply-To: References: <03a1e8e3dd121e62b848f4c73393d24a1277a67d_refs_heads_master@pld-linux.org> Message-ID: <20160620190504.GA21851@mail> On Mon, Jun 20, 2016 at 08:01:33PM +0200, glen wrote: > commit aaeb56b0e6b7f2a6f5e636a50ab7e67f1c047aff > Author: Elan Ruusam?e > Date: Mon Jun 20 21:01:12 2016 +0300 > > future todo: use .7z download .7z (and .zip) boost archives are targeted to Windows (with CRLF line endings inside). -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Mon Jun 20 21:06:53 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 20 Jun 2016 21:06:53 +0200 Subject: python packaging In-Reply-To: References: <5767E863.50803@pld-linux.org> Message-ID: <20160620190653.GB21851@mail> On Mon, Jun 20, 2016 at 04:11:41PM +0200, Jacek Konieczny wrote: > On 2016-06-20 14:58, Elan Ruusam?e wrote: > >so, what way we should do the package naming? > > > >1. egg name > > That probably makes most sense today. > > >2. python module name [*] > > That was decided before python eggs started being a thing. And that is > how most of our packages are named now. Also, some packages contain more than one module without own namespace, thus making using import name for whole package impossible. -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Mon Jun 20 21:25:29 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 20 Jun 2016 22:25:29 +0300 Subject: [packages/boost] future todo: use .7z download In-Reply-To: <20160620190504.GA21851@mail> References: <03a1e8e3dd121e62b848f4c73393d24a1277a67d_refs_heads_master@pld-linux.org> <20160620190504.GA21851@mail> Message-ID: <57684329.1070004@pld-linux.org> On 20.06.2016 22:05, Jakub Bogusz wrote: > On Mon, Jun 20, 2016 at 08:01:33PM +0200, glen wrote: >> commit aaeb56b0e6b7f2a6f5e636a50ab7e67f1c047aff >> Author: Elan Ruusam?e >> Date: Mon Jun 20 21:01:12 2016 +0300 >> >> future todo: use .7z download > .7z (and .zip) boost archives are targeted to Windows (with CRLF line > endings inside). there .7z is smaller than .bz2, and if the only difference is EOL-style, then gcc doesn't mind source file encoding... -- glen From glen at pld-linux.org Mon Jun 20 21:27:44 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 20 Jun 2016 22:27:44 +0300 Subject: python packaging In-Reply-To: <20160620190653.GB21851@mail> References: <5767E863.50803@pld-linux.org> <20160620190653.GB21851@mail> Message-ID: <576843B0.9080504@pld-linux.org> On 20.06.2016 22:06, Jakub Bogusz wrote: > On Mon, Jun 20, 2016 at 04:11:41PM +0200, Jacek Konieczny wrote: >> On 2016-06-20 14:58, Elan Ruusam?e wrote: >>> so, what way we should do the package naming? >>> >>> 1. egg name >> That probably makes most sense today. >> >>> 2. python module name [*] >> That was decided before python eggs started being a thing. And that is >> how most of our packages are named now. > Also, some packages contain more than one module without own namespace, > thus making using import name for whole package impossible. but egg name or pypi name? i would prefer pypi name, because most docs say install from pypi: $ pip install foothing and then can just type instead: $ poldek -u python-foothing -- glen From qboosh at pld-linux.org Tue Jun 21 21:46:33 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 21 Jun 2016 21:46:33 +0200 Subject: [packages/boost] future todo: use .7z download In-Reply-To: <57684329.1070004@pld-linux.org> References: <03a1e8e3dd121e62b848f4c73393d24a1277a67d_refs_heads_master@pld-linux.org> <20160620190504.GA21851@mail> <57684329.1070004@pld-linux.org> Message-ID: <20160621194633.GA519@mail> On Mon, Jun 20, 2016 at 10:25:29PM +0300, Elan Ruusam?e wrote: > On 20.06.2016 22:05, Jakub Bogusz wrote: > >On Mon, Jun 20, 2016 at 08:01:33PM +0200, glen wrote: > >>commit aaeb56b0e6b7f2a6f5e636a50ab7e67f1c047aff > >>Author: Elan Ruusam?e > >>Date: Mon Jun 20 21:01:12 2016 +0300 > >> > >> future todo: use .7z download > >.7z (and .zip) boost archives are targeted to Windows (with CRLF line > >endings inside). > > there .7z is smaller than .bz2, and if the only difference is EOL-style, > then gcc doesn't mind source file encoding... I don't know, if the only. But CRs in headers and (at least part of) docs make binary packages bigger. (Yes, they could be stripped etc. at build time - but 12% smaller source package is unlikely worth complicating build process) -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Mon Jun 27 13:10:59 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 27 Jun 2016 14:10:59 +0300 Subject: python packaging In-Reply-To: <5767E863.50803@pld-linux.org> References: <5767E863.50803@pld-linux.org> Message-ID: <577109C3.2010104@pld-linux.org> On 20.06.2016 15:58, Elan Ruusam?e wrote: > > 1. egg name > 2. python module name [*] > 3. upstream tarball name > 4. pld own convention > > [*] this is said to be the recommendation in template-specs oh, one more! the egg filename and egg name also may mismatch: ? rpm -q python-Levenshtein -l |grep egg /usr/lib64/python2.7/site-packages/python_Levenshtein-0.10-py2.7.egg-info ? rpm -q python-Levenshtein --provides |grep egg pythonegg(python-levenshtein) = 0.10 -- glen From qboosh at pld-linux.org Tue Jun 28 22:28:09 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 28 Jun 2016 22:28:09 +0200 Subject: python packaging In-Reply-To: <577109C3.2010104@pld-linux.org> References: <5767E863.50803@pld-linux.org> <577109C3.2010104@pld-linux.org> Message-ID: <20160628202809.GA14228@mail> On Mon, Jun 27, 2016 at 02:10:59PM +0300, Elan Ruusam?e wrote: > On 20.06.2016 15:58, Elan Ruusam?e wrote: > > > >1. egg name > >2. python module name [*] > >3. upstream tarball name > >4. pld own convention > > > >[*] this is said to be the recommendation in template-specs > > oh, one more! the egg filename and egg name also may mismatch: > > ??? rpm -q python-Levenshtein -l |grep egg > /usr/lib64/python2.7/site-packages/python_Levenshtein-0.10-py2.7.egg-info > > ??? rpm -q python-Levenshtein --provides |grep egg > pythonegg(python-levenshtein) = 0.10 It seems that pythonegg provides are lowercased. (to be verified in rpm .prov script, no time atm.) -- Jakub Bogusz http://qboosh.pl/ From qboosh at pld-linux.org Wed Jun 29 20:44:44 2016 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 29 Jun 2016 20:44:44 +0200 Subject: python packaging In-Reply-To: <20160628202809.GA14228@mail> References: <5767E863.50803@pld-linux.org> <577109C3.2010104@pld-linux.org> <20160628202809.GA14228@mail> Message-ID: <20160629184444.GA19426@mail> On Tue, Jun 28, 2016 at 10:28:09PM +0200, Jakub Bogusz wrote: > On Mon, Jun 27, 2016 at 02:10:59PM +0300, Elan Ruusam?e wrote: > > On 20.06.2016 15:58, Elan Ruusam?e wrote: > > > > > >1. egg name > > >2. python module name [*] > > >3. upstream tarball name > > >4. pld own convention > > > > > >[*] this is said to be the recommendation in template-specs > > > > oh, one more! the egg filename and egg name also may mismatch: > > > > ??? rpm -q python-Levenshtein -l |grep egg > > /usr/lib64/python2.7/site-packages/python_Levenshtein-0.10-py2.7.egg-info > > > > ??? rpm -q python-Levenshtein --provides |grep egg > > pythonegg(python-levenshtein) = 0.10 > > It seems that pythonegg provides are lowercased. > (to be verified in rpm .prov script, no time atm.) rpm pythoneggs script relies on Distribution.key property, which is (in Python pkg_resources system module) equal to lowercase 'name' egg field. -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Wed Jun 29 23:56:27 2016 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 30 Jun 2016 00:56:27 +0300 Subject: python packaging In-Reply-To: <20160629184444.GA19426@mail> References: <5767E863.50803@pld-linux.org> <577109C3.2010104@pld-linux.org> <20160628202809.GA14228@mail> <20160629184444.GA19426@mail> Message-ID: <5774440B.1040905@pld-linux.org> On 29.06.2016 21:44, Jakub Bogusz wrote: > On Tue, Jun 28, 2016 at 10:28:09PM +0200, Jakub Bogusz wrote: >> On Mon, Jun 27, 2016 at 02:10:59PM +0300, Elan Ruusam?e wrote: >>> On 20.06.2016 15:58, Elan Ruusam?e wrote: >>>> 1. egg name >>>> 2. python module name [*] >>>> 3. upstream tarball name >>>> 4. pld own convention >>>> >>>> [*] this is said to be the recommendation in template-specs >>> oh, one more! the egg filename and egg name also may mismatch: >>> >>> ??? rpm -q python-Levenshtein -l |grep egg >>> /usr/lib64/python2.7/site-packages/python_Levenshtein-0.10-py2.7.egg-info >>> >>> ??? rpm -q python-Levenshtein --provides |grep egg >>> pythonegg(python-levenshtein) = 0.10 >> It seems that pythonegg provides are lowercased. >> (to be verified in rpm .prov script, no time atm.) > rpm pythoneggs script relies on Distribution.key property, which is (in > Python pkg_resources system module) equal to lowercase 'name' egg > field. yes, it's lowercase and all unknown chars are changed to "-", that includes "_" don't have the source code reference right now, but i checked from from distribute module source > > -- glen