[glibc] branch sid updated (d8d823b -> 5ae6713)

2016-12-19 Thread Aurelien Jarno 
This is an automated email from the git hooks/post-receive script.

aurel32 pushed a change to branch sid
in repository glibc.

  from  d8d823b   fix whitespace
   new  5ae6713   debian/patches/localedata/supported.diff: rename the 
kk_KZ locale with the RK1048 charset to kk_KZ.RK1048 to avoid conflicting with 
the kk_KZ locale with the PT154 charset.  Closes: #847596.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 debian/changelog | 3 +++
 debian/patches/localedata/supported.diff | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

[glibc] branch sid updated (a7f30bd -> d8d823b)

2016-12-19 Thread Samuel Thibault 
This is an automated email from the git hooks/post-receive script.

sthibault pushed a change to branch sid
in repository glibc.

  from  a7f30bd   hurd: tg-magic-pid: fix spurious port deallocation
   new  d8d823b   fix whitespace

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "adds" were already present in the repository and have only
been added to this reference.


Summary of changes:
 debian/patches/hurd-i386/tg-magic-pid.diff | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

Processed: Bug#847596 marked as pending

2016-12-19 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> tag 847596 pending
Bug #847596 [locales-all] locales-all non-deterministically generates either 
kk_KZ.PT154 or kk_KZ.RK1048 despite declaring support for both
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
847596: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847596
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

[glibc] 01/01: debian/patches/localedata/supported.diff: rename the kk_KZ locale with the RK1048 charset to kk_KZ.RK1048 to avoid conflicting with the kk_KZ locale with the PT154 charset. Closes: #847

2016-12-19 Thread Aurelien Jarno 
This is an automated email from the git hooks/post-receive script.

aurel32 pushed a commit to branch sid
in repository glibc.

commit 5ae6713759807bf3116f673dfbd2c8ac726e4c7d
Author: Aurelien Jarno 
Date:   Mon Dec 19 12:21:24 2016 +0100

debian/patches/localedata/supported.diff: rename the kk_KZ locale with the 
RK1048 charset to kk_KZ.RK1048 to avoid conflicting with the kk_KZ locale with 
the PT154 charset.  Closes: #847596.
---
 debian/changelog | 3 +++
 debian/patches/localedata/supported.diff | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index ab28e82..c6ace96 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,6 +14,9 @@ glibc (2.24-9) UNRELEASED; urgency=medium
   * debian/rules.d/build.mk: pass --no-recursion before -T in the call to tar
 to workaround or fix bug#829738. This reduces the size of the glibc-source
 package by 40%
+  * debian/patches/localedata/supported.diff: rename the kk_KZ locale with the
+RK1048 charset to kk_KZ.RK1048 to avoid conflicting with the kk_KZ locale
+with the PT154 charset.  Closes: #847596.
 
  -- Samuel Thibault   Fri, 09 Dec 2016 01:51:00 +0100
 
diff --git a/debian/patches/localedata/supported.diff 
b/debian/patches/localedata/supported.diff
index 420cae8..da17f29 100644
--- a/debian/patches/localedata/supported.diff
+++ b/debian/patches/localedata/supported.diff
@@ -35,7 +35,7 @@
  ka_GE/GEORGIAN-PS \
  kk_KZ.UTF-8/UTF-8 \
  kk_KZ/PT154 \
-+kk_KZ/RK1048 \
++kk_KZ.RK1048/RK1048 \
  kl_GL.UTF-8/UTF-8 \
  kl_GL/ISO-8859-1 \
  km_KH/UTF-8 \

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

[glibc] 01/01: fix whitespace

2016-12-19 Thread Samuel Thibault 
This is an automated email from the git hooks/post-receive script.

sthibault pushed a commit to branch sid
in repository glibc.

commit d8d823b9c7a5bcf05f1270d1d106a63220d7454e
Author: Samuel Thibault 
Date:   Mon Dec 19 12:12:40 2016 +0100

fix whitespace
---
 debian/patches/hurd-i386/tg-magic-pid.diff | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/patches/hurd-i386/tg-magic-pid.diff 
b/debian/patches/hurd-i386/tg-magic-pid.diff
index 6647c27..120ac6d 100644
--- a/debian/patches/hurd-i386/tg-magic-pid.diff
+++ b/debian/patches/hurd-i386/tg-magic-pid.diff
@@ -152,7 +152,7 @@ index aee2ba8..6ed8de1 100644
 -return EGRATUITOUS;
 +err = EGRATUITOUS;
 +goto out;
-   }
+   }
  break;
  
default:

-- 
Alioth's /usr/local/bin/git-commit-notice on 
/srv/git.debian.org/git/pkg-glibc/glibc.git

Bug#783210: glibc: please make the package build reproducibly

2016-12-19 Thread Holger Levsen 
On Mon, Dec 19, 2016 at 10:11:00AM +, Ximin Luo wrote:
> It is not strictly necessary, but it allows one to build reproducibly even 
> when not using dpkg-buildpackage, e.g. when trying to re-run a specific part 
> of the build via `debian/rules build` or something else. This is helpful to 
> save time when debugging.

using dpkg-buildpackage is also not mandatory, eg developers could build
with "./debian/rules binary" initially and upload this to the archive…


-- 
cheers,
Holger

(and yes, we need to get rid off developer built uploads, _except_ for
bootstrapping only… amen.)


signature.asc
Description: Digital signature

Bug#783210: glibc: please make the package build reproducibly

2016-12-19 Thread Ximin Luo 
Aurelien Jarno:
> [..]
> 
> It would be nice to have an explanation why the changes from your patch
> are needed. See my comments below.
> 
> 
>> diff -Nru glibc-2.24/debian/rules glibc-2.24/debian/rules
>> --- glibc-2.24/debian/rules  2016-11-25 21:59:04.0 +
>> +++ glibc-2.24/debian/rules  2016-11-15 18:03:37.0 +
>> @@ -45,6 +45,7 @@
>>  
>>  DEB_SOURCE_PACKAGE := $(strip $(shell egrep '^Source: ' debian/control | 
>> cut -f 2 -d ':'))
>>  
>> +SOURCE_DATE_EPOCH ?= $(shell dpkg-parsechangelog -STimestamp)
>>  DEB_VERSION := $(shell dpkg-parsechangelog | egrep '^Version:' | cut -f 2 
>> -d ' ')
>>  GLIBC_VERSION = $(shell echo $(DEB_VERSION) | sed -e 's/.*://' -e 
>> 's/[+-].*//')
> 
> You told above that SOURCE_DATE_EPOCH is already set by
> dpkg-buildpackage, so why do we need to do that?
> 

It is not strictly necessary, but it allows one to build reproducibly even when 
not using dpkg-buildpackage, e.g. when trying to re-run a specific part of the 
build via `debian/rules build` or something else. This is helpful to save time 
when debugging.

>> diff -Nru glibc-2.24/debian/rules.d/build.mk 
>> glibc-2.24/debian/rules.d/build.mk
>> --- glibc-2.24/debian/rules.d/build.mk   2016-11-25 12:02:24.0 
>> +
>> +++ glibc-2.24/debian/rules.d/build.mk   2016-11-15 18:03:37.0 
>> +
>> @@ -316,18 +316,16 @@
>>  $(stamp)source: $(stamp)patch
>>  mkdir -p $(build-tree)
>>  cd .. && \
>> -   find $(GLIBC_SOURCES) -depth -newermt '$(DEB_BUILD_DATE)' \
>> --print0 | \
>> -   xargs -0r touch --no-dereference --date='$(DEB_BUILD_DATE)'
>> -cd .. && \
>>  find $(GLIBC_SOURCES) -print0 | \
>>  LC_ALL=C sort -z | \
>>  tar -c -J --null -T - --no-recursion \
>>  --mode=go=rX,u+rw,a-s \
>> +--clamp-mtime --mtime "@$(SOURCE_DATE_EPOCH)" \
>>  --owner=root --group=root --numeric-owner \
>>  -f $(CURDIR)/$(build-tree)/glibc-$(GLIBC_VERSION).tar.xz
>>  mkdir -p debian/glibc-source/usr/src/glibc
>>  tar cf - --files-from debian/glibc-source.filelist \
>> +--clamp-mtime --mtime "@$(SOURCE_DATE_EPOCH)" \
>>| tar -x -C debian/glibc-source/usr/src/glibc -f -
> 
> Why do we need to change this, what doesn't work in the current code? The 
> current code
> has been provided by Jérémy Bobbio in the current bug.
> 

Yes, it doesn't work. but also it was not applied correctly:

1. The original patch had a mistake in: we need "@$(unix_timestamp)", the '@' 
tells GNU find/tar/date/etc to interpret the subsequent value as a UNIX 
timestamp. Otherwise these tools will complain about an invalid date, but 
silently use a different value.

2. The original patch was not applied fully/correctly either - nowhere in the 
current glibc packaging is DEB_BUILD_DATE actually set. The original patch set 
this, instead of my previous hunk that sets SOURCE_DATE_EPOCH, however this is 
not present in the current glibc packaging.

3. Since the original patch was written, we got the --clamp-mtime feature into 
GNU tar, and this allows us to make the patch smaller and the resulting code is 
neater. (It also avoids writing directly to the filesystem.)

>>  touch $@
>> diff -Nru glibc-2.24/debian/rules.d/debhelper.mk 
>> glibc-2.24/debian/rules.d/debhelper.mk
>> --- glibc-2.24/debian/rules.d/debhelper.mk   2016-11-25 22:08:30.0 
>> +
>> +++ glibc-2.24/debian/rules.d/debhelper.mk   2016-11-15 18:03:37.0 
>> +
>> @@ -77,8 +77,7 @@
>>  -exec chmod a+x '{}' ';'
>>  dh_makeshlibs -Xgconv/ -p$(curpass) -V "$(call xx,shlib_dep)"
>>  # Add relevant udeb: lines in shlibs files
>> -chmod a+x debian/shlibs-add-udebs
>> -./debian/shlibs-add-udebs $(curpass)
>> +sh ./debian/shlibs-add-udebs $(curpass)
>>  
>>  dh_installdeb -p$(curpass)
>>  dh_shlibdeps -p$(curpass)
> 
> Why do we need this change?
> 

This is not strictly necessary, but it helps one perform reproductions in the 
same source tree, by running dpkg-buildpackage twice. Otherwise, glibc-source 
has -x for that file in the first build and +x for that file in the second 
build.

Yes, our testing infrastructure does not run builds twice in the same source 
tree and neither does debrepro nor reprotest, however doing this is useful for 
debugging purposes, to save time and avoid having to re-run the whole build 
againg.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#842660: marked as done (/usr/bin/tzselect returns "11) MSK+03 - Novosibirsk" when we have lately had "11) MSK+04 - Novosibirsk" in our city on Debian 7 "Wheezy")

2016-12-19 Thread Debian Bug Tracking System 
Your message dated Mon, 19 Dec 2016 10:04:49 +0100
with message-id <20161219090449.gd4...@aurel32.net>
and subject line Re: /usr/bin/tzselect returns "11) MSK+03 - Novosibirsk" when 
we have lately had "11) MSK+04 - Novosibirsk" in our city on Debian 7 "Wheezy"
has caused the Debian Bug report #842660,
regarding /usr/bin/tzselect returns "11) MSK+03 - Novosibirsk" when we have 
lately had "11) MSK+04 - Novosibirsk" in our city on Debian 7 "Wheezy"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
842660: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842660
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tzdata
Version: 2016h-0+deb7u1
Hello there!
I've got a problem when using "tzselect" for the city of Novosibirsk (Russia).
tzselect returns +03 as a timezone, but we've been lately declared to be using 
+04 for the city.
Please fix the bug.
Thanks.
---
Sincerely yours,
Artem--- End Message ---
--- Begin Message ---
On 2016-12-19 11:11, Artem wrote:
> I can't reproduce the bug. Unfortunately, everything works fine. You may 
> close the task.

Thanks for your answer, I am closing the bug with this mail.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net--- End Message ---

Bug#842660: Re[2]: /usr/bin/tzselect returns "11) MSK+03 - Novosibirsk" when we have lately had "11) MSK+04 - Novosibirsk" in our city on Debian 7 "Wheezy"

2016-12-19 Thread Artem 
I can't reproduce the bug. Unfortunately, everything works fine. You may close 
the task.



>Понедельник, 19 декабря 2016, 4:22 +07:00 от Aurelien Jarno 
>:
>
>control: tag -1 + moreinfo
>
>Hi,
>
>On 2016-10-31 11:06, Artem wrote:
>> Package: tzdata
>> Version: 2016h-0+deb7u1
>> Hello there!
>> I've got a problem when using "tzselect" for the city of Novosibirsk 
>> (Russia).
>> tzselect returns +03 as a timezone, but we've been lately declared to be 
>> using +04 for the city.
>
>I am not able to reproduce your issue:
>
>$ dpkg -l tzdata
>Desired=Unknown/Install/Remove/Purge/Hold
>| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>||/ Name  Version Architecture
>Description
>+++-=-===-===-===
>ii  tzdata2016h-0+deb7u1  all time 
>zone and daylight-saving time data
>
>$ TZ="Europe/Moscow" date
>Mon Dec 19 00:20:49 MSK 2016
>
>$ TZ="Asia/Novosibirsk" date
>Mon Dec 19 04:20:53 +07 2016
>
>So the date is correctly set as MSK+4. Could you please try the above
>commands on your machine?
>
>Thanks,
>Aurelien
>
>-- 
>Aurelien Jarno  GPG: 4096R/1DDD8C9B
>aurel...@aurel32.net http://www.aurel32.net