Hi,
Nearly every day I get new libreoffice packages from Tumbleweed. My zypper history log: 2011-05-05 15:20:19|libreoffice|3.3.2.2-1.12 2011-05-09 15:20:35|libreoffice|3.3.2.2-1.13 2011-05-10 23:40:35|libreoffice|3.3.2.2-1.15 2011-05-15 16:30:15|libreoffice|3.3.2.2-1.16 2011-05-16 15:41:48|libreoffice|3.3.2.2-1.17 2011-05-17 18:18:29|libreoffice|3.3.2.2-1.18 2011-05-19 11:29:28|libreoffice|3.3.2.2-1.19 2011-05-20 21:56:30|libreoffice|3.3.2.2-1.20
Why are there so much rebuilds? Downloading ~200MiB everyday sucks.
On Fri, May 20, 2011 at 09:58:53PM +0200, richard -rw- weinberger wrote:
Hi,
Nearly every day I get new libreoffice packages from Tumbleweed. My zypper history log: 2011-05-05 15:20:19|libreoffice|3.3.2.2-1.12 2011-05-09 15:20:35|libreoffice|3.3.2.2-1.13 2011-05-10 23:40:35|libreoffice|3.3.2.2-1.15 2011-05-15 16:30:15|libreoffice|3.3.2.2-1.16 2011-05-16 15:41:48|libreoffice|3.3.2.2-1.17 2011-05-17 18:18:29|libreoffice|3.3.2.2-1.18 2011-05-19 11:29:28|libreoffice|3.3.2.2-1.19 2011-05-20 21:56:30|libreoffice|3.3.2.2-1.20
Why are there so much rebuilds? Downloading ~200MiB everyday sucks.
Well, it's every few days, not every day :)
And yes, it does suck, but there have been a lot of library changes that have caused these rebuilds. I've worked with the libreoffice developers to try to reduce some of these dependancies, but some of them are real, and can't be removed. A lot of this is due to the new KDE being in Tumbleweed now.
I'm trying to only do a libreoffice once a week, but the KDE/Qt changes recently have caused this to happen more than I want, sorry.
Oh, you forgot to complain about the kernel changes all the time too, that's probably more than 200Mb...
thanks,
greg k-h
On Fri, May 20, 2011 at 11:57 PM, Greg KH gregkh@suse.de wrote:
Oh, you forgot to complain about the kernel changes all the time too, that's probably more than 200Mb...
I run my own kernels. :P
Ah ... I'm an LXDE desktop Tumbleweed user and I don't have KDE installed, so perhaps that explains why I don't see so many libreoffice package updates (I see some, but not many).
Lee
On 05/20/2011 11:57 PM, Greg KH wrote:
On Fri, May 20, 2011 at 09:58:53PM +0200, richard -rw- weinberger wrote:
Hi,
Nearly every day I get new libreoffice packages from Tumbleweed. .... Why are there so much rebuilds? Downloading ~200MiB everyday sucks.
And yes, it does suck, but there have been a lot of library changes that have caused these rebuilds. I've worked with the libreoffice developers to try to reduce some of these dependancies, but some of them are real, and can't be removed. A lot of this is due to the new KDE being in Tumbleweed now.
El 20/05/11 15:58, richard -rw- weinberger escribió:
Hi,
Nearly every day I get new libreoffice packages from Tumbleweed. My zypper history log: 2011-05-05 15:20:19|libreoffice|3.3.2.2-1.12 2011-05-09 15:20:35|libreoffice|3.3.2.2-1.13 2011-05-10 23:40:35|libreoffice|3.3.2.2-1.15 2011-05-15 16:30:15|libreoffice|3.3.2.2-1.16 2011-05-16 15:41:48|libreoffice|3.3.2.2-1.17 2011-05-17 18:18:29|libreoffice|3.3.2.2-1.18 2011-05-19 11:29:28|libreoffice|3.3.2.2-1.19 2011-05-20 21:56:30|libreoffice|3.3.2.2-1.20
Why are there so much rebuilds? Downloading ~200MiB everyday sucks.
This happends because there are differences one ONE file usr/share/libreoffice/basis3.3/share/registry/res/registry_af.xcd
Other libreoffice packages republish randomly for the same reason the kernel does, maintainers have not fixed the "file-contains-current-date" and "file-contains-date-and-time" build system watnings.
I suggest you to bug them hard in order to stop the annoyance.
Cheers.
On Sat, May 21, 2011 at 05:47:54PM -0400, Cristian Rodríguez wrote:
El 20/05/11 15:58, richard -rw- weinberger escribió:
Hi,
Nearly every day I get new libreoffice packages from Tumbleweed. My zypper history log: 2011-05-05 15:20:19|libreoffice|3.3.2.2-1.12 2011-05-09 15:20:35|libreoffice|3.3.2.2-1.13 2011-05-10 23:40:35|libreoffice|3.3.2.2-1.15 2011-05-15 16:30:15|libreoffice|3.3.2.2-1.16 2011-05-16 15:41:48|libreoffice|3.3.2.2-1.17 2011-05-17 18:18:29|libreoffice|3.3.2.2-1.18 2011-05-19 11:29:28|libreoffice|3.3.2.2-1.19 2011-05-20 21:56:30|libreoffice|3.3.2.2-1.20
Why are there so much rebuilds? Downloading ~200MiB everyday sucks.
This happends because there are differences one ONE file usr/share/libreoffice/basis3.3/share/registry/res/registry_af.xcd
Other libreoffice packages republish randomly for the same reason the kernel does, maintainers have not fixed the "file-contains-current-date" and "file-contains-date-and-time" build system watnings.
What needs to be fixed here?
And when does the kernel "randomly" rebuild? I haven't seen it rebuild other than for very good reasons in Tumbleweed.
I suggest you to bug them hard in order to stop the annoyance.
What specifically needs to be done?
thanks,
greg k-h
El 21/05/11 18:23, Greg KH escribió:
And when does the kernel "randomly" rebuild? I haven't seen it rebuild other than for very good reasons in Tumbleweed.
Ok, the kernel may not be a good example.
I suggest you to bug them hard in order to stop the annoyance.
What specifically needs to be done?
Fix the the build system warnings, that is:
a) removing the usage of constants __DATE__ or __TIME__ from source code
Or more uglier and probably not wanted:
b) redefine __DATE__ and __TIME__ in the GCC command line to some proper value that doesnt change unless the source code or the changes file has been updated-
On Sat, May 21, 2011 at 07:04:11PM -0400, Cristian Rodríguez wrote:
El 21/05/11 18:23, Greg KH escribió:
I suggest you to bug them hard in order to stop the annoyance.
What specifically needs to be done?
Fix the the build system warnings, that is:
a) removing the usage of constants __DATE__ or __TIME__ from source code
Or more uglier and probably not wanted:
b) redefine __DATE__ and __TIME__ in the GCC command line to some proper value that doesnt change unless the source code or the changes file has been updated-
I don't understand why that would cause libreoffice to stop rebuilding due to dependancy changes, do you?
confused,
greg k-h
El 21/05/11 20:30, Greg KH escribió:
I don't understand why that would cause libreoffice to stop rebuilding due to dependancy changes, do you?
Would not stop rebuilding, but republishing if the binaries are equal and differ just on build date time.
On 05/22/2011 12:23 AM, Greg KH wrote:
On Sat, May 21, 2011 at 05:47:54PM -0400, Cristian Rodríguez wrote:
El 20/05/11 15:58, richard -rw- weinberger escribió:
Hi,
Nearly every day I get new libreoffice packages from Tumbleweed. My zypper history log: 2011-05-05 15:20:19|libreoffice|3.3.2.2-1.12 2011-05-09 15:20:35|libreoffice|3.3.2.2-1.13 2011-05-10 23:40:35|libreoffice|3.3.2.2-1.15 2011-05-15 16:30:15|libreoffice|3.3.2.2-1.16 2011-05-16 15:41:48|libreoffice|3.3.2.2-1.17 2011-05-17 18:18:29|libreoffice|3.3.2.2-1.18 2011-05-19 11:29:28|libreoffice|3.3.2.2-1.19 2011-05-20 21:56:30|libreoffice|3.3.2.2-1.20
Why are there so much rebuilds? Downloading ~200MiB everyday sucks.
This happends because there are differences one ONE file usr/share/libreoffice/basis3.3/share/registry/res/registry_af.xcd
Other libreoffice packages republish randomly for the same reason the kernel does, maintainers have not fixed the "file-contains-current-date" and "file-contains-date-and-time" build system watnings.
What needs to be fixed here?
Patch libreoffice to not use __DATE__ and __TIME__ macros. Look for example at the writer build log: https://build.opensuse.org/stage/package/rawlog?arch=x86_64&package=libr...
and search for file-contains-date-and-time to see where these macros were used.
thanks,
Jiri Slaby wrote:
On 05/22/2011 12:23 AM, Greg KH wrote:
On Sat, May 21, 2011 at 05:47:54PM -0400, Cristian Rodríguez wrote:
El 20/05/11 15:58, richard -rw- weinberger escribió:
Nearly every day I get new libreoffice packages from Tumbleweed. My zypper history log: 2011-05-05 15:20:19|libreoffice|3.3.2.2-1.12 2011-05-09 15:20:35|libreoffice|3.3.2.2-1.13 2011-05-10 23:40:35|libreoffice|3.3.2.2-1.15 2011-05-15 16:30:15|libreoffice|3.3.2.2-1.16 2011-05-16 15:41:48|libreoffice|3.3.2.2-1.17 2011-05-17 18:18:29|libreoffice|3.3.2.2-1.18 2011-05-19 11:29:28|libreoffice|3.3.2.2-1.19 2011-05-20 21:56:30|libreoffice|3.3.2.2-1.20
Why are there so much rebuilds? Downloading ~200MiB everyday sucks.
This happends because there are differences one ONE file usr/share/libreoffice/basis3.3/share/registry/res/registry_af.xcd
Other libreoffice packages republish randomly for the same reason the kernel does, maintainers have not fixed the "file-contains-current-date" and "file-contains-date-and-time" build system watnings.
What needs to be fixed here?
Patch libreoffice to not use __DATE__ and __TIME__ macros. Look for example at the writer build log: https://build.opensuse.org/stage/package/rawlog?arch=x86_64&package=libr...
and search for file-contains-date-and-time to see where these macros were used.
Should we assign some badness value to this warning ie make it an error? There are currently 118 packages in Factory with file-contains-date-and-time.
cu Ludwig
On Mon, 2011-05-23 at 09:07 +0200, Ludwig Nussel wrote:
Should we assign some badness value to this warning ie make it an error? There are currently 118 packages in Factory with file-contains-date-and-time.
Badness is good :) But not too much: there is already a huge list of build failures in oS:F at the moment (OTOH: why not know: the list probably won't get much longer).
For a start: can you make a list (if possible sorted by devel project) of the packages that are affected?
This could get the people already 'on track' before all packages are failing.
Then maybe 2 weeks after publishing the list, we give it a high enough badness to have packages fail. That should be sufficient.
Dominique
Dimstar / Dominique Leuenberger wrote:
On Mon, 2011-05-23 at 09:07 +0200, Ludwig Nussel wrote:
Should we assign some badness value to this warning ie make it an error? There are currently 118 packages in Factory with file-contains-date-and-time.
Badness is good :) But not too much: there is already a huge list of build failures in oS:F at the moment (OTOH: why not know: the list probably won't get much longer).
For a start: can you make a list (if possible sorted by devel project) of the packages that are affected?
Here's the list (sorting by devel project left as exercise ;-)
2138 netbeans-platform 1204 libwpd 134 libwpg 93 libreoffice-libs-core 65 libreoffice-filters 54 libreoffice-ure 53 libreoffice-libs-gui 44 brltty 37 libreoffice-components 34 jakarta-commons-dbcp 27 jakarta-commons-pool 19 kernel-debug 17 kernel-xen 17 kernel-trace 17 kernel-desktop 17 kernel-default 16 kernel-vanilla 15 libreoffice-calc 10 libreoffice-base 9 kdelibs4-apidocs 8 mozilla-nss 8 evoldap2-client 7 oprofile 7 licq 7 libreoffice-writer 7 libreoffice-impress 6 clisp 5 pdns 5 kernel-ec2 4 libreoffice-extensions 4 freeradius-server 3 perl 3 pax-utils 3 libpst 3 kdelibs3-devel-doc 3 jpilot 3 gnokii 3 elfutils 3 eciadsl-usermode 3 dx 3 CodeAnalyst 2 ZynAddSubFX 2 uudeview 2 swipl 2 squid 2 rrdtool 2 python3 2 pidentd 2 photorec 2 mozilla-xulrunner20 2 meanwhile 2 libtheora 2 libreoffice-libs-extern 2 libdlm 2 hercules 2 fvwm-themes 2 ffado-mixer 2 blktrace 2 bind 1 zypper 1 zimg 1 yast2-hardware-detection 1 xemacs 1 wxWidgets-ansi 1 tin 1 spawn-fcgi 1 socat 1 snd 1 slrn 1 qtractor 1 qt-creator 1 qjackctl 1 python-curl 1 pysol 1 pilot-link 1 pdns-recursor 1 openmcu 1 openivr 1 ocfs2-tools 1 nxtvepg 1 ntop 1 newsbeuter 1 ncftp 1 mysql-cluster 1 multitail 1 mozilla-xulrunner192 1 lyx 1 linuxrc 1 lighttpd 1 libzypp 1 libreoffice-testing 1 kvpnc 1 krename 1 kompozer 1 kdebase3 1 kbuild 1 jumpnbump 1 jhead 1 java-1_6_0-openjdk 1 i4l-base 1 ht 1 gnugk 1 geany-plugins 1 fvwm2 1 filezilla 1 ffado 1 epic 1 dvbsnoop 1 djvulibre 1 dd_rescue 1 ctags 1 clamav 1 beaver 1 avrdude 1 anjuta 1 abiword
cu Ludwig
as long as there is no clear policy on how the error message should be removed, personally I will not do it.
if we consider this is a bug in the programs should we report it upstream with the devs, maybe even attach our patches?
if the thing is just a matter of personal taste only we should move on..
regards, Alin
On 23 May 2011 08:07, Ludwig Nussel ludwig.nussel@suse.de wrote:
Jiri Slaby wrote:
On 05/22/2011 12:23 AM, Greg KH wrote:
On Sat, May 21, 2011 at 05:47:54PM -0400, Cristian Rodríguez wrote:
El 20/05/11 15:58, richard -rw- weinberger escribió:
Nearly every day I get new libreoffice packages from Tumbleweed. My zypper history log: 2011-05-05 15:20:19|libreoffice|3.3.2.2-1.12 2011-05-09 15:20:35|libreoffice|3.3.2.2-1.13 2011-05-10 23:40:35|libreoffice|3.3.2.2-1.15 2011-05-15 16:30:15|libreoffice|3.3.2.2-1.16 2011-05-16 15:41:48|libreoffice|3.3.2.2-1.17 2011-05-17 18:18:29|libreoffice|3.3.2.2-1.18 2011-05-19 11:29:28|libreoffice|3.3.2.2-1.19 2011-05-20 21:56:30|libreoffice|3.3.2.2-1.20
Why are there so much rebuilds? Downloading ~200MiB everyday sucks.
This happends because there are differences one ONE file usr/share/libreoffice/basis3.3/share/registry/res/registry_af.xcd
Other libreoffice packages republish randomly for the same reason the kernel does, maintainers have not fixed the "file-contains-current-date" and "file-contains-date-and-time" build system watnings.
What needs to be fixed here?
Patch libreoffice to not use __DATE__ and __TIME__ macros. Look for example at the writer build log: https://build.opensuse.org/stage/package/rawlog?arch=x86_64&package=libr...
and search for file-contains-date-and-time to see where these macros were used.
Should we assign some badness value to this warning ie make it an error? There are currently 118 packages in Factory with file-contains-date-and-time.
cu Ludwig
-- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Alin Marin Elena wrote:
as long as there is no clear policy on how the error message should be removed, personally I will not do it.
It depends on why upstream included the timestamp in the first place. If the timestamp doesn't serve any real purpose just patch it away. I think Cristian fixed many packages in this regard. Cristian, could you maybe add a paragraph to http://en.opensuse.org/openSUSE:Packaging_checks to explain the easiest or most common fix?
if we consider this is a bug in the programs should we report it upstream with the devs, maybe even attach our patches?
if the thing is just a matter of personal taste only we should move on..
It's neither a real bug in the package nor a matter of personal taste. The build service automatically rebuilds depending packages to keep the system consistent. If a package includes a time stamp in a file the build service can't determine anymore whether the build result is the same after an automatic rebuild. Therefore it's annoying for users of Factory/Tumbleweed as they get package updates that only contain some timestamp change.
cu Ludwig
* Ludwig Nussel ludwig.nussel@suse.de [2011-05-23 09:08]:
Should we assign some badness value to this warning ie make it an error? There are currently 118 packages in Factory with file-contains-date-and-time.
No, not in its current state which produces false positives. I use a hack to replace __DATE__ and __TIME__ with the date and time extracted from the .changes file:
modified="$(sed -n '/^----/n;s/ - .*$//;p;q' "%{_sourcedir}/%{name}.changes")" DATE=""$(date -d "${modified}" "+%%b %%e %%Y")"" TIME=""$(date -d "${modified}" "+%%R")"" find . -name '*.[ch]' -print0 |\ xargs -0 sed -i "s/__DATE__/${DATE}/g;s/__TIME__/${TIME}/g"
This has the advantage that the application will still have some halfway useful date and time information where it expects it. Unfortunately rpmlint still complains at least for the first build because it checks for the current date in the binary.
Am 23.05.2011 10:42, schrieb Guido Berhoerster:
- Ludwig Nussel ludwig.nussel@suse.de [2011-05-23 09:08]:
Should we assign some badness value to this warning ie make it an error? There are currently 118 packages in Factory with file-contains-date-and-time.
No, not in its current state which produces false positives. I use a hack to replace __DATE__ and __TIME__ with the date and time extracted from the .changes file:
modified="$(sed -n '/^----/n;s/ - .*$//;p;q' "%{_sourcedir}/%{name}.changes")" DATE=""$(date -d "${modified}" "+%%b %%e %%Y")"" TIME=""$(date -d "${modified}" "+%%R")"" find . -name '*.[ch]' -print0 |\ xargs -0 sed -i "s/__DATE__/${DATE}/g;s/__TIME__/${TIME}/g"
This has the advantage that the application will still have some halfway useful date and time information where it expects it. Unfortunately rpmlint still complains at least for the first build because it checks for the current date in the binary.
I used this method for my quassel rpms and I get still a file-contains-date-and-time for the first build after a change. This is because the modification time ist close to the build time in many cases.
Herbert
* Herbert Graeber lists@graeber-clan.de [2011-05-23 12:41]:
Am 23.05.2011 10:42, schrieb Guido Berhoerster:
- Ludwig Nussel ludwig.nussel@suse.de [2011-05-23 09:08]:
Should we assign some badness value to this warning ie make it an error? There are currently 118 packages in Factory with file-contains-date-and-time.
No, not in its current state which produces false positives. I use a hack to replace __DATE__ and __TIME__ with the date and time extracted from the .changes file:
modified="$(sed -n '/^----/n;s/ - .*$//;p;q' "%{_sourcedir}/%{name}.changes")" DATE=""$(date -d "${modified}" "+%%b %%e %%Y")"" TIME=""$(date -d "${modified}" "+%%R")"" find . -name '*.[ch]' -print0 |\ xargs -0 sed -i "s/__DATE__/${DATE}/g;s/__TIME__/${TIME}/g"
This has the advantage that the application will still have some halfway useful date and time information where it expects it. Unfortunately rpmlint still complains at least for the first build because it checks for the current date in the binary.
I used this method for my quassel rpms and I get still a file-contains-date-and-time for the first build after a change. This is because the modification time ist close to the build time in many cases.
Yes, that is what I was trying to say above :). The rpmlint-check needs improvements before it can be made fatal.
Guido Berhoerster wrote:
- Ludwig Nussel ludwig.nussel@suse.de [2011-05-23 09:08]:
Should we assign some badness value to this warning ie make it an error? There are currently 118 packages in Factory with file-contains-date-and-time.
No, not in its current state which produces false positives. I use a hack to replace __DATE__ and __TIME__ with the date and time extracted from the .changes file:
modified="$(sed -n '/^----/n;s/ - .*$//;p;q' "%{_sourcedir}/%{name}.changes")" DATE=""$(date -d "${modified}" "+%%b %%e %%Y")"" TIME=""$(date -d "${modified}" "+%%R")"" find . -name '*.[ch]' -print0 |\ xargs -0 sed -i "s/__DATE__/${DATE}/g;s/__TIME__/${TIME}/g"
This has the advantage that the application will still have some halfway useful date and time information where it expects it. Unfortunately rpmlint still complains at least for the first build because it checks for the current date in the binary.
Avoiding false positives about the time could probably be fixed by providing the time stamp of the build start to rpmlint. Fixing the warning about the date isn't easily possible though unless we build packages always only the day after the last change :-)
cu Ludwig
-
Alin Marin Elena -
Cristian Rodríguez -
Dimstar / Dominique Leuenberger -
Greg KH -
Guido Berhoerster -
Herbert Graeber -
Jiri Slaby -
Ludwig Nussel -
oldcpu -
richard -rw- weinberger