On Tue, 26 Feb 2019 15:05:54 +0100, Florin Portase <portase.flo...@medianetork.ro> wrote: > >On 2019-02-22 22:30, Robert Paschedag wrote: > > Am 22. Februar 2019 13:11:00 MEZ schrieb Florin Portase <portase.flo...@medianetork.ro>: On 2019-02-13 10:56, Florin Portase wrote: >> >> Hello, >> >> I just have upgraded the spacewalk server from 2.7 => 2.9. >> >> Just to mention spacewalk 2.7 + patches was working just fine for both debian & ubuntu. >> Now, for ubuntu 16.05 I have over 100 packages marked as up-gradable( >> over and over. >> ... >> So, after digging through SPW archive Dec '18 til Feb '19 finally I >> come to something more acceptable: >> >> 1. sync script for Ubuntu channels >> >> 2. "spacewalk-add-debian-multiarch-header.py.NEW " took it from >>... >Below is your error > >Packages.new is the "modified" Packages which you rename and >*afterwards* use its "modified" timestamp. This is wrong. > >You have to use the "modified" timestamp of the "original" (the one generated by Spacewalk) packages file > >So when you have the original "Packages" file (by spacewalk), do > >- run the <add_header> script (which generates "Packages.new") >- gzip -c Packages.new > Packages.gz >- touch -r Packages Packages.new Packages.gz && mv Packages.new Packages > >So you have transferred the original timestamp to the new files and all set to "secure" your repo then. > >Robert > >>> /bin/mv $_PKG_MAIN/Packages.new $_PKG_MAIN/Packages /bin/mv >>> $_PKG_SEC/Packages.new $_PKG_SEC/Packages /bin/mv >>> $_PKG_UPD/Packages.new $_PKG_UPD/Packages /bin/mv >>> $_PKG_UNIV/Packages.new $_PKG_UNIV/Packages >>> >>> gzip < $_PKG_MAIN/Packages > $_PKG_MAIN/Packages.gz gzip < >>> $_PKG_UPD/Packages > $_PKG_UPD/Packages.gz gzip < $_PKG_SEC/Packages
>>> > $_PKG_SEC/Packages.gz gzip < $_PKG_UNIV/Packages > >>> $_PKG_UNIV/Packages.gz >>> >>> Here I run into another problem, it seems taskomatic is generating >>> Package files over and over ( touch -r Packages.gz Packages seems to >>> have no effect) >> >> This seems to be new. You might have to check within code, at which >> conditions a rebuild of the Packages file gets triggered >> >> I'm still on SW2.7 so I cannot test on my environment. >> >> Robert > BTW, I was having a similar issue with automated (Taskomatic?) regeneration of the package files, wiping out the customized package files on my xenial and bionic channels that had been rebuilt to include the additional (DEP11?) metadata headers such as MultiArch:. The timestamps were being re-assigned correctly however, so I couldn't figure out why until some time after I read Robert's e-mail above. It turns out that, for Ubuntu 16 and 18, I was using the SecureApt.sh script to build the signed Release and InRelease files for those channels and repos. Since those aren't part of the standard channel cache files automatically-generated by Spacewalk, I thought it would be OK. Nope. I since modified the SecureApt.sh to modify the timestamp on the signed Release files to match the Package timestamp and that seems to have fixed the problem, although I won't really know for sure until another week. Cheers, Paul-Andre _______________________________________________ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
