Bug#801083: gthumb: unreproducible build

[hpfn]

beautiful -> typo fixed.


-- 
Herbert Parentes Fortes Neto (hpfn)

Bug#801083: gthumb: unreproducible build

[hpfn]

Hi Alex,

> Hi Herbert,
> 
> Do you know how the bug is fixed? Well, do the bug disappears itself,
> or is it an upstream fix? Anyway, congratulations!
> 

I don't know. It disappears by itself. Is the
same version.

In testing we have the cloud with rain and
in sid a beatiful sun. Same version.


regards,
-- 
Herbert Parentes Fortes Neto (hpfn)

Bug#801083: gthumb: unreproducible build

[Alex Vong]

Hi Herbert,

Do you know how the bug is fixed? Well, do the bug disappears itself,
or is it an upstream fix? Anyway, congratulations!

Cheers,
Alex

On 16/10/2015, Herbert Parentes Fortes Neto  wrote:
> Hi Alex,
>
> No 'unrep' on my QA page today.
>
> I will wait a few more days and if nothing
> changes, I will close the bug.
>
>
>
> regards,
> --
> Herbert Parentes Fortes Neto (hpfn)
>

Bug#801083: gthumb: unreproducible build

[hpfn]

Hi Alex,

No 'unrep' on my QA page today.

I will wait a few more days and if nothing
changes, I will close the bug.



regards,
-- 
Herbert Parentes Fortes Neto (hpfn)

Bug#801083: gthumb: unreproducible build

[hpfn]

Hi Alex,

> Hi,
> 
> I have looked into the buildd page for gthumb
> .
> 
> It seems that particular FTBFS is due the build machine not having
> enough disk space. This is indicated by the error message `autoreconf:
> cannot create /tmp/ar9681.28668: No space left on device', which is on
> the very end of the buildd page. Does this make sense to you?
> 

I saw the other email too. And checked the page of build.

First says 'sufficient free space for build'. Then
there is 'no space left on device'.

No sense.

regards,
-- 
Herbert Parentes Fortes Neto (hpfn)

Bug#801083: gthumb: unreproducible build

[Alex Vong]

Hi,

I have looked into the buildd page for gthumb
.

It seems that particular FTBFS is due the build machine not having
enough disk space. This is indicated by the error message `autoreconf:
cannot create /tmp/ar9681.28668: No space left on device', which is on
the very end of the buildd page. Does this make sense to you?

Cheers,
Alex

On 10/10/2015, Herbert Parentes Fortes Neto  wrote:
> Hi,
>
> I looked the 'Build history' today.
>
> A same version (3.4.0) can be reproducible and
> unreproducible (a lot of them). The last build
> of this version even FTBFS.
>
> Difficult to come to a conclusion.
>
>
> regards,
> --
> Herbert Parentes Fortes Neto (hpfn)
>

Bug#801083: gthumb: unreproducible build

[hpfn]

Hi,

I looked the 'Build history' today.

A same version (3.4.0) can be reproducible and
unreproducible (a lot of them). The last build 
of this version even FTBFS.

Difficult to come to a conclusion.


regards,
-- 
Herbert Parentes Fortes Neto (hpfn)

Bug#801083: gthumb: unreproducible build

[hpfn]

> The file is generated by glib-mkenums (libglib2.0-dev package).
> The cmd is present in configure:
> 
> gnome-multi-writer-3.17.92/configure: $(AM_V_GEN) glib-mkenums --comments 
> '\'''\'' --fhead "" --vhead "  <@type@ 
> id='\''$(gsettings_ENUM_NAMESPACE).@EnumName@'\''>" --vprod " nick='\''@valuenick@'\'' value='\''@valuenum@'\''/>" --vtail "  " 
> --ftail "" $^ > $@.tmp && mv $@.tmp $@
> 
> The file seems to be different but only the order.
> The values inside a tag, let's say 
> ,
> is the same. I checked the file I have installed with the result at
> reproducible.debian.net
> 
> As it is a generated file, maybe is the way it is. 
> It is my guess for now. But the bug still open.

Humm...

I maintain another package that uses glib-mkenums,
gnome-multi-writer. It doesn't has a 'unrep' on my
DDPO page.


regards,
-- 
Herbert Parentes Fortes Neto (hpfn)

Bug#801083: gthumb: unreproducible build

[hpfn]

Hi Alex,

> Source: gthumb
> Version: 3:3.4.1-1
> Severity: minor
> 
> Dear Maintainer,
> 
> 
> shows that the version of gthumb in unstable is unreproducible. The
> ``differences'' tag shows that the file to be installed as
> /usr/share/glib-2.0/schemas/org.gnome.gthumb.enums.xml cannot be built
> reproducibly.
> 
> The build log diff shows org.gnome.gthumb.enums.xml is being built
> using different commands in different builds! I think this is why
> org.gnome.gthumb.enums.xml cannot be built reproducibly.

Thanks to explain the log.

The file is generated by glib-mkenums (libglib2.0-dev package).
The cmd is present in configure:

gnome-multi-writer-3.17.92/configure:   $(AM_V_GEN) glib-mkenums --comments 
'\'''\'' --fhead "" --vhead "  <@type@ 
id='\''$(gsettings_ENUM_NAMESPACE).@EnumName@'\''>" --vprod "" --vtail "  " 
--ftail "" $^ > $@.tmp && mv $@.tmp $@

The file seems to be different but only the order.
The values inside a tag, let's say 
,
is the same. I checked the file I have installed with the result at
reproducible.debian.net

As it is a generated file, maybe is the way it is. 
It is my guess for now. But the bug still open.


regards,
-- 
Herbert Parentes Fortes Neto (hpfn)

Bug#801083: gthumb: unreproducible build

[Alex Vong]

Source: gthumb
Version: 3:3.4.1-1
Severity: minor

Dear Maintainer,


shows that the version of gthumb in unstable is unreproducible. The
``differences'' tag shows that the file to be installed as
/usr/share/glib-2.0/schemas/org.gnome.gthumb.enums.xml cannot be built
reproducibly.

The build log diff shows org.gnome.gthumb.enums.xml is being built
using different commands in different builds! I think this is why
org.gnome.gthumb.enums.xml cannot be built reproducibly.

Cheers,
Alex


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)